JP2024031735A - Source code modification support device and source code modification support method - Google Patents

Abstract

An object of the present invention is to reduce the labor involved in replacing part of a source code with a description in another language. A source code modification support device includes an acquisition section, a structure analysis section, and a determination section. The acquisition unit generates metrics by assigning a reference value for determining program complexity and an evaluation value corresponding to the program complexity to each of multiple metrics items related to analysis of source code structure. Get the rule list. The structure analysis unit determines whether or not each program module in the source code written in the first language violates the standard value corresponding to each metrics item, and identifies metrics that violate the standard value. Calculate the evaluation score representing the sum of evaluation values corresponding to the item. The determination unit determines whether or not each program module needs to be replaced with a second language based on the evaluation score calculated by the structure analysis unit. [Selection diagram] Figure 1

Description

The present invention relates to an apparatus and method for supporting the task of replacing a description in a source code with a description in another language.

As opportunities for connecting to networks have increased, there has also been an increase in the number of cases in which malicious third parties are targeting software vulnerabilities and causing problems. For this reason, work is being done to discover software vulnerabilities during the development stage by analyzing source code based on predetermined secure coding rules. This ensures the safety of the software. For example, secure coding rules such as CERT (Computer Emergency Response Team), MISRA (The Motor Industry Software Reliability Association), and AUTOSAR (Automotive Open System Architecture) are used in fields such as automotive equipment, industrial equipment, and medical equipment. .

In addition, programming languages that reduce software vulnerabilities are becoming popular. For example, Rust is a language that guarantees memory safety, and is attracting attention as one of the languages that can replace the C language or C++.

Note that a source program analysis device that points out errors in the execution processing order of a source program has been proposed (for example, Patent Document 1). Furthermore, a source code conversion device has been proposed that converts source code written in one programming language to source code written in another programming language (for example, Patent Document 2). Furthermore, devices that support program modification or debugging have been proposed (for example, Patent Documents 3 and 4).

Japanese Patent Application Publication No. 2006-236042 Japanese Patent Application Publication No. 2010-140408 Japanese Patent Application Publication No. 2021-192201 JP2009-104252A

As mentioned above, highly reliable programming languages such as Rust are becoming popular. On the other hand, there is a desire to continue using existing software products as much as possible in order to reduce the cost and time required for program development. Therefore, in order to deal with vulnerabilities in existing software, static analysis equipment may be used to identify locations that contain vulnerabilities, and only the identified locations may be rewritten with a description in a highly reliable language.

However, in large-scale programs, the number of locations containing vulnerabilities increases. For this reason, it takes a long time to rewrite all parts that contain vulnerabilities with descriptions in a highly reliable language.

An object of one aspect of the present invention is to reduce the labor involved in replacing part of a source code written in one language with one written in another language.

A source code modification support device according to one aspect of the present invention provides a reference value for determining the complexity of a program for each of a plurality of metrics items related to analysis of the structure of a source code, and an evaluation corresponding to the complexity of the program. A metrics rule list acquisition unit that acquires a metrics rule list created by assigning values, and each metric registered in the metrics rule list for each program module in the source code written in the first language. a structural analysis unit that determines whether or not a standard value corresponding to each item is violated, and calculates an evaluation score representing the sum of evaluation values corresponding to metrics items that violate the standard value; and the structural analysis unit and a determination unit that determines a response policy for each program module based on the evaluation score calculated by.

According to the above aspect, it is possible to reduce the labor involved in replacing part of a source code written in a certain language with a description in another language.

FIG. 1 is a diagram showing an example of a source code modification support device according to an embodiment of the present invention. FIG. 3 is a diagram showing an example of a metrics list. 3 is a flowchart illustrating an example of processing by a metrics rule creation unit. It is a figure showing an example of an evaluation value list and a metrics rule list. 5 is a flowchart illustrating an example of processing by a structure analysis unit. It is a figure which shows an example of the analysis result list showing the analysis result by a structure analysis part. 7 is a flowchart illustrating an example of processing by a determination unit. It is a figure showing an example of a foreign language substitution list and a foreign processing list. 3 is a flowchart illustrating an example of processing by a source code modification device and a testing device. FIG. 7 is a diagram showing an example of a source code modification support device according to a second embodiment of the present invention. It is a figure which shows an example of a secure coding rule. FIG. 3 is a diagram showing an example of a priority list and a security rule list. 3 is a flowchart illustrating an example of processing by a static analysis unit. FIG. 3 is a diagram illustrating an example of a search result list representing search results of a static analysis unit. It is a flowchart which shows an example of the process of the determination part in the 2nd Embodiment of this invention. It is a figure showing an example of the other language substitution list and the other processing list in the 2nd embodiment of the present invention. It is a figure showing an example of a source code modification support device concerning a 3rd embodiment of the present invention. It is a figure showing an example of a template. 7 is a flowchart illustrating an example of processing by a template search unit. FIG. 2 is a diagram (part 1) showing an example of a search result list representing search results by a template search unit. FIG. 7 is a diagram (part 2) illustrating an example of a search result list representing search results by the template search unit. It is a flowchart which shows an example of the process of the determination part in the 3rd Embodiment of this invention. 21 is a diagram showing a state in which priorities are assigned to each program module registered in the search result list shown in FIG. 20. FIG. 22 is a diagram showing a state in which priorities are assigned to each program module registered in the search result list shown in FIG. 21. FIG. FIG. 6 is a diagram showing a variation of the embodiment of the present invention. FIG. 2 is a diagram illustrating an example of the hardware configuration of a source code modification support device.

FIG. 1 shows an example of a source code modification support device according to an embodiment of the present invention. The source code modification support device 1 according to the embodiment of the present invention extracts high-risk program modules from the source code 2 based on metrics analysis, and outputs information representing a countermeasure for each extracted program module. do. Note that a program module is not particularly limited, but means, for example, a set of descriptions or processes corresponding to one function. In this case, the function shall include a method.

Source code 2 is a pre-compiled program code written in a predetermined programming language. Although not particularly limited, it is assumed in this embodiment that the source code 2 is written in C language or C++. Further, the source code 2 may be a program code used as an existing software product. Furthermore, source code 2 includes multiple program modules.

As shown in FIG. 2, the metrics list 3 has registered therein indicators (that is, metrics) for quantitatively indicating the complexity (including scale, maintainability, etc.) of the source code. For example, cyclomatic complexity detects the value obtained by adding 1 to the number of branch condition paths used in the source code. Possible branch conditions include "if-then," "for-next," "case," "catch," and "while." Further, the maximum nesting number (MaxNesting) represents the nesting depth (or the number of stages of nested structure) of functions used in the source code.

As shown in FIG. 1, the source code modification support device 1 includes a metrics rule list creation section 11, a metrics rule list acquisition section 12, a structure analysis section 13, and a determination section 14. Note that the source code modification support device 1 may include other functions or devices not shown in FIG.

The metrics list 3 is provided to the metrics rule list creation unit 11 . Here, as described above, one or more metrics items are registered in the metrics list 3. Then, the metrics rule list creation unit 11 creates a metrics rule list by assigning a reference value and an evaluation value to each metrics item. Note that the metrics rule list creation unit 11 is realized, for example, by an operator who modifies the source code 2 operating a computer.

FIG. 3 is a flowchart showing an example of the processing of the metrics rule list creation unit 11. The processing in this flowchart is executed, for example, when the source code 2 is provided to the source code modification support device 1. However, the metrics rule list creation unit 11 may execute the process of the flowchart shown in FIG. 3 before the source code 2 is provided to the source code modification support device 1.

In S1, the metrics rule list creation unit 11 creates an evaluation value list related to a countermeasure when modifying the source code 2. As shown in FIG. 4(a), the evaluation value list 21 represents the definition of evaluation values to be given to each metrics item registered in the metrics list 3. The evaluation value is determined, for example, based on the severity of the security risk when the standard value of the metric item is exceeded. In this embodiment, evaluation values are set in three stages, but evaluation values in two stages, four stages or more may be set.

The response policy represents how to handle a program module that exceeds the standard value of the relevant metrics item. In this embodiment, the policy shown in FIG. 4(a) is set depending on the evaluation value. That is, "replace with description in another language" is set for a program module that exceeds the standard of the metrics item to which the evaluation value "3" with the highest risk is assigned. For program modules that exceed the standards of metrics items that are given the second highest risk evaluation value of "2," "recommended to be replaced with description in another language" is set. "Modify based on a predetermined policy" is set for a program module that exceeds the standard of the metrics item to which the lowest risk evaluation value "1" is assigned.

In S2, the metrics rule list creation unit 11 obtains the metrics list 3 given to the source code modification support device 1. In S3, the metrics rule list creation unit 11 acquires a reference value corresponding to each metrics item. This reference value corresponds to, for example, a threshold value for determining whether a program module is complicated. Further, it is assumed that this reference value is determined in advance. In S4, the metrics rule list creation unit 11 creates a metrics rule list by assigning a reference value and an evaluation value corresponding to each metrics item in the metrics list 3. In this embodiment, the metrics rule list 22 shown in FIG. 4(b) is obtained by assigning a predetermined reference value and the evaluation value shown in FIG. 4(a) to each metrics item shown in FIG. 2.

For example, if the source code includes a program module that exceeds the impact scale (ImpactScale) standard value, it is considered that a serious failure may occur. Therefore, a large evaluation value of "3" is assigned to this metrics item. In addition, when the source code includes a program module that exceeds the standard value of lack of condensation (PercentLackOfCohesion), although some failures may occur, it is considered that the possibility of serious failures is not high. . Therefore, this metrics item is given an intermediate evaluation value of "2". Furthermore, even if a program module includes a program module that exceeds the standard values for cyclomatic complexity (Cyclomatic), maximum number of nests (MaxNesting), and number of inputs (CountInput), it is considered that the possibility of serious failures occurring is low. . Therefore, a small evaluation value of "1" is assigned to these metric items.

The reference value and/or evaluation value given to each metrics item may be determined, for example, by a worker who modifies the source code 2. In this case, the worker operates the computer to create the metrics rule list 22 shown in FIG. 4(b). The created metrics rule list 22 is stored in a memory (not shown) included in the source code modification support device 1.

The metrics rule list acquisition unit 12 acquires the metrics rule list 22 created by the procedure shown in FIG. In this embodiment, the metrics rule list acquisition unit 12 reads the metrics rule list 22 shown in FIG. 4(b) from the memory included in the source code modification support device 1.

The structure analysis unit 13 searches the source code 2 for a complex program module with a high risk based on the metrics rule list 22 acquired by the metrics rule list acquisition unit 12. That is, the structure analysis unit 13 searches the source code 2 for a program module that violates the standard value of each metrics item. In this embodiment, "violating the standard value" means exceeding the standard value.

FIG. 5 is a flowchart showing an example of processing by the structure analysis unit 13. The process of this flowchart is executed when the source code 2 is given to the source code modification support device 1. However, it is assumed that the metrics rule list 22 shown in FIG. 4(b) has been created before the processing in this flowchart is executed.

In S11, the structure analysis unit 13 obtains the source code 2. In S12, the structure analysis unit 13 searches for a violating module in the source code 2 according to the metrics rule list 22 created in the procedure shown in FIG. At this time, the structure analysis unit 13 determines whether the description content of each program module in the source code 2 exceeds the reference value of the metrics item. Then, in S13, the structure analysis unit 13 outputs an analysis result list representing the analysis results.

FIG. 6 shows an example of an analysis result list representing the analysis results by the structure analysis unit 13. In this embodiment, the source code 2 includes a main program whose file name is "main.c" and a subprogram whose file name is "sub.c."

As shown in FIG. 6A, the analysis result list 23 indicates whether the written content of each program module violates each metrics item registered in the metrics rule list 22. That is, an "O" mark indicates that the program module does not violate the standard value of the metric item, and an "x" mark indicates that the program module violates the standard value of the metric item. In this embodiment, it is assumed that each program module in the source code 2 is identified by a combination of a "file name" and a "function name." Moreover, "position" represents the position (line number) where the function of each program module is described.

For example, the analysis results for a program module identified by "file name: main.c" and "function name: main()" are as follows.
(1) Cyclomatic = 10, standard value = 10 → below standard value (no violation)
(2) MaxNesting = 5, standard value = 7 → below standard value (no violation)
(3) PercentLackOfCohesion = 15, standard value = 20 → below standard value (no violation)
(4) ImpactScale = 10, standard value = 8 → exceeds standard value (violation)
(5) CountInput = 8, standard value = 15 → below standard value (no violation)
The structure analysis unit 13 calculates the evaluation score by adding up the evaluation points corresponding to the metrics items in which the violation has occurred. In this example, a violation occurs only for "ImpactScale". The evaluation value corresponding to "ImpactScale" is "3". Therefore, the evaluation score for this program module is "3".

Furthermore, the analysis results for the program module identified by "File name: main.c" and "Function name: func()" are as follows.
(1) Cyclomatic = 15, standard value = 10 → exceeds standard value (violation)
(2) MaxNesting = 6, standard value = 7 → below standard value (no violation)
(3) PercentLackOfCohesion = 25, standard value = 20 → exceeds standard value (violation)
(4) ImpactScale=3, standard value=8 → below standard value (no violation)
(5) CountInput = 10, standard value = 15 → below standard value (no violation)
In this example, violations occur for "Cyclomatic" and "PercentLackOfCohesion." The evaluation values corresponding to "Cyclomatic" and "PercentLackOfCohesion" are "1" and "2", respectively. Therefore, the evaluation score for this program module is "3".

In this way, the structure analysis unit 13 calculates the evaluation score of each program module. As a result, an analysis result list 23 is created.

The structure analysis unit 13 may create an analysis result list 24 showing an overview of the analysis results, as shown in FIG. 6(b). The analysis result list 24 includes, for each file, the number of lines of source code that was analyzed, the total number of program modules in which violations were detected, the number of program modules in which violations were detected for each evaluation value, and the evaluation for each file. Represents the total value of points. For example, the search results for the main program indicate that 3, 2, and 8 violations of metrics items with evaluation values of "3," "2," and "1" were detected, respectively.

The determining unit 14 determines the handling policy for each program module based on the analysis result by the structure analyzing unit 13. Specifically, the determination unit 14 determines the handling policy for each program module based on the evaluation score calculated by the structure analysis unit 13.

FIG. 7 is a flowchart illustrating an example of the processing of the determination unit 14. It is assumed that the analysis result list 23 has been created by the structure analysis section 13 before executing the processing in this flowchart.

In S21, the determination unit 14 obtains the analysis result list created by the structure analysis unit 13. At this time, the determination unit 14 obtains an analysis result list (for example, the analysis result list 23 shown in FIG. 6A) in which evaluation scores are calculated for each program module. In S22, the determination unit 14 selects a program module from the analysis result list. In the embodiment shown in FIG. 6(a), each program module is identified by a combination of a file name and a function name. In S23 and S24, the determining unit 14 checks the evaluation score of the selected program module.

When the evaluation score of the selected program module is zero, the determination unit 14 determines that there is no problem with the program module. In this case, the determination unit 14 adds the selected program module to the unprocessed list in S25. The unprocessed list is a list for registering program modules whose descriptions do not need to be changed. However, the determination unit 14 does not necessarily need to execute the process of S25.

When the evaluation score of the selected program module is greater than a predetermined threshold, the determination unit 14 determines that the risk associated with the program module is high. In this case, the determination unit 14 adds the selected program module to the other language replacement list 25 shown in FIG. 8(a) in S26. The other language replacement list 25 is a list for registering program modules that need to be replaced with other languages with high reliability. Note that in this example, the threshold value in S24 is "2". That is, program modules with evaluation scores of 3 or more are registered in the other language replacement list 25.

When the evaluation score of the selected program module is not zero but is equal to or less than the above-mentioned threshold, the determination unit 14 determines that the program module has a risk, but the risk is not very serious. In this case, the determination unit 14 adds the selected program module to the other processing list 26 shown in FIG. 8(b) in S27. The other processing list 26 is a list for registering program modules that should execute processing other than processing for replacing the language with another language.

In S28, the determination unit 14 checks whether any program modules that have not undergone the processes in S23 to S27 remain in the analysis result list. If a program module that has not undergone the processes of S23 to S27 remains in the analysis result list, the process of the determination unit 14 returns to S22. That is, the next program module is selected from the analysis result list. Thereafter, the processes of S23 to S27 are executed for the newly selected program module. Then, when the processes of S23 to S27 are executed for all program modules registered in the analysis result list, the process of the determination unit 14 ends. As a result, the other language replacement list 25 and the other processing list 26 are created.

For example, it is assumed that the analysis result list 23 shown in FIG. 6(a) is given to the determination unit 14. Then, the determination unit 14 executes the processes of S23 to S27 for each program module registered in the analysis result list 23. Here, it is assumed that the threshold value used in S24 is "2". In this case, the evaluation score of the program module identified by "file name: main.c" and "function name: main()" is "3". Then, the determination unit 14 adds this module to the other language replacement list 25. Furthermore, the program module identified by “file name: main.c” and “function name: func()” is also added to the other language replacement list 25. The evaluation score of the program module identified by "file name: main.c" and "function name: aaa()" is "1". Then, the determination unit 14 adds this module to the other processing list 26. Furthermore, a program module identified by “file name: sub.c” and “function name: sub_com2()” is also added to the other processing list 26. As a result, the other language replacement list 25 shown in FIG. 8(a) and the other processing list 26 shown in FIG. 8(b) are obtained.

Note that the other language replacement list 25 instructs to replace the first language (C/C++) with a second language (Rust) that is more reliable than the first language (C/C++) as a policy for dealing with program modules whose evaluation scores exceed a threshold value. This is an example of information. Further, the procedure shown in FIG. 7 is one example, and the embodiments of the present invention are not limited to this procedure.

In this way, the source code modification support device 1 analyzes each program module in the source code 2 based on the metrics list 3. At this time, each program module is given an evaluation score that indicates the severity of the security risk (or the degree of necessity of replacing it with a highly reliable programming language). Then, the source code modification support device 1 creates the other language replacement list 25 and other processing list 26 by grouping each program module using this evaluation score. Thereafter, the other language replacement list 25 and other processing list 26 are provided to the source code modification device 4 shown in FIG.

The source code modification device 4 modifies the source code 2 based on the other language replacement list 25 and the other processing list 26 created by the source code modification support device 1. The test device 5 then executes the source code 2 modified by the source code modification device 4 to check the operation. Note that the source code modification device 4 and the testing device 5 are realized, for example, by an operator who modifies the source code 2 operating a computer.

FIG. 9 is a flowchart showing an example of processing by the source code modification device 4 and the testing device 5. In this embodiment, the source code modification device 4 obtains the source code 2 in S41. Further, the source code modification device 4 obtains the other language replacement list 25 and the other processing list 26 created by the source code modification support device 1 in S42 and S45, respectively.

The processes of S43 to S44 are executed for each violating module registered in the other language replacement list 25. That is, in S43, the source code correction device 4 replaces the violating module with a description in another language. For example, when the source code 2 is written in the C language, the violating module is replaced with a description in the Rust language. At this time, a worker who modifies the source code 2 may manually rewrite the code using a computer that implements the source code modification device 4. Alternatively, when the source code modification device 4 has a conversion function from the C language to the Rust language, the source code modification device 4 replaces the violating module with a description in the Rust language. In this case, the source code modification device 4 operates as a conversion unit that converts the violating module, which has been determined by the determination unit 14 to be replaced with a description in another language, into a Rust description. Note that although it is not easy to convert the entire program code into another language through software processing, it is possible to convert part of the description into another language using existing technology.

In S44, the test device 5 compiles and executes the description replaced with another language. That is, a test is performed as to whether the violating module has been correctly replaced with another language. The test results are then fed back to the source code modification device 4. At this time, if the violating module has not been correctly replaced with another language, the source code modification device 4 further modifies its description. As a result, each violating module registered in the other language replacement list 25 is correctly replaced with another language.

The processes in S46 and S47 are executed for each violating module registered in the other process list 26. That is, in S46, the source code modification device 4 modifies the violating module without changing the language of the source code. For example, when the source code 2 is written in C language, the content of the violating module is modified while remaining in C language. At this time, the operator who modifies the source code 2 may manually modify the code using a computer that implements the source code modification device 4. Alternatively, the source code modification device 4 may output a report indicating that the violating module has not been modified, without modifying the violating module.

In S47, the test device 5 compiles and executes the modified description. That is, a test is performed to determine whether the violating module has been correctly corrected. This test result is then fed back to the source code modification device 4. At this time, if the violating module has not been corrected correctly, the source code correction device 4 further corrects its description. As a result, each violating module registered in the other processing list 26 is corrected correctly. Note that if the violating module is not corrected in S46, it is not necessary to execute the process in S47.

In S48, the testing device 5 combines the description replaced with another language and the modified description into the source code 2. Then, the test device 5 tests the program including the description replaced with another language and the modified description.

In this way, the source code modification support device 1 determines the severity of security risks (or reliability) for each program module in the source code based on metrics for analyzing the structure of the source code. An evaluation score representing the degree of necessity of replacing the program with a higher-level programming language is assigned. Therefore, a worker who modifies the source code 2 can easily recognize program modules that pose a high degree of security risk even if the size of the source code is large. In other words, even in cases where it is difficult to rewrite the entire source code in another language due to cost or workload considerations, program modules with high security risks can be reliably written in a highly reliable programming language. can be replaced with This reduces the risk of existing unreliable programs even when cost or effort constraints exist.

<Second embodiment>
In the embodiments shown in FIGS. 1 to 8, high-risk program modules are extracted using metrics that analyze the structure of source code. In contrast, in the second embodiment of the present invention, in addition to metrics, secure coding rules are also used to extract high-risk program modules. Secure coding rules are an example of rules that must be followed when writing source code.

FIG. 10 shows an example of a source code modification support device according to the second embodiment of the present invention. In the second embodiment of the present invention, the source code modification support device 1B has a function of searching the source code 2 for a violation description based on the secure coding rule 30. Note that the source code 2 is substantially the same in FIGS. 1 and 10, and is a pre-compiled program code written in a predetermined programming language.

The secure coding rules 30 are information that lists rules that must be followed when writing source code, and are used when the source code modification support device 1B analyzes the source code 2. In this embodiment, the source code modification support device 1B uses an existing coding rule as the secure coding rule 30. For example, CERT, MISRA, or AUTOSAR is used as the secure coding rule 30. As an example, FIG. 11 shows a part of the CERT-C/C++ coding standard convention used in analyzing code written in C/C++.

As shown in FIG. 10, the source code modification support device 1B includes a metrics rule list creation unit 11, a metrics rule list acquisition unit 12, a structure analysis unit 13, a security rule list creation unit 31, a security rule list acquisition unit 32, a static It includes an analysis section 33 and a determination section 14B. Note that the metrics rule list creation section 11, the metrics rule list acquisition section 12, and the structure analysis section 13 are substantially the same in FIGS. 1 and 10. Further, the source code modification support device 1B may include other functions or devices not shown in FIG.

A secure coding rule 30 is provided to the security rule list creation unit 31. The secure coding rules 30 represent one or more rules that must be followed when writing source code, as described above. Then, the security rule list creation unit 31 creates a security rule list by assigning a priority to each rule listed as the secure coding rules 30. Note that the security rule list creation section 31 is realized, for example, by an operator who modifies the source code 2 operating a computer.

The security rule list creation unit 31 creates a priority list related to the policy when modifying the source code 2. The priority list 41 defines the priority given to each rule prepared as the secure coding rule 30, as shown in FIG. 12(a). The priority is determined, for example, based on the severity of the security risk when a violation of the rule occurs. In this embodiment, three levels of priority are set, but two, four or more levels of priority may be set.

The handling policy indicates how to deal with a description that violates the rule. In this embodiment, the policy shown in FIG. 12(a) is set according to the priority. That is, "replace with description in another language" is set for a description that violates the rule to which level 3, which has the highest priority, is assigned. For descriptions that violate the rules that are given level 2, which has the second highest priority, "recommended to replace with descriptions in other languages" is set. "Modify based on a predetermined policy" is set for a description that violates a rule to which level 1, which has the lowest priority, is assigned.

The security rule list creation unit 31 acquires the secure coding rules 30 given to the source code modification support device 1B. Then, the security rule list creation unit 31 creates a security rule list by assigning a priority to each rule that must be followed when writing source code. In this embodiment, the security rule list 42 shown in FIG. 12(b) is obtained by assigning the priority shown in FIG. 12(a) to each rule shown in FIG. 11.

For example, if the source code contains a statement that violates the rule ``Ensure that signed integer operations do not cause overflow'' identified in ``INT32-C,'' a serious failure may occur. it is conceivable that. Therefore, a high priority of "3" is given to this rule. The same applies to the rules identified by "INT33-C" and "EXP33-C". Additionally, if the source code contains a statement that violates the rule ``Ensure that the size argument of variable-length arrays is within an appropriate range'' identified in ``ARR32-C,'' some kind of failure may occur. However, it is considered that the possibility of serious failure occurring is not high. Therefore, this rule is given an intermediate level of priority "2". On the other hand, even if the source code contains a statement that violates the rule "Do not directly manipulate time_t type values" identified in "MSC05-C", we believe that there is a low possibility that a serious failure will occur. It will be done. Therefore, this rule is given a low priority of "1".

The priority given to each rule may be determined, for example, by a worker who modifies the source code 2. In this case, the operator operates the computer to create the security rule list 42 shown in FIG. 12(b). The created security rule list 42 is stored in a memory (not shown) included in the source code modification support device 1B.

The security rule list acquisition unit 32 acquires the security rule list 42 created in the above-described procedure. In this example, the security rule list acquisition unit 32 reads the security rule list 42 shown in FIG. 12(b) from the memory included in the source code modification support device 1B.

The static analysis unit 33 searches the source code 2 for violation descriptions based on the security rule list 42 acquired by the security rule list acquisition unit 32. That is, the static analysis unit 33 searches the source code 2 for a violation description that violates the rules listed in the security rule list 42.

FIG. 13 is a flowchart illustrating an example of processing by the static analysis unit 33. The processing in this flowchart is executed when source code 2 is provided to source code modification support device 1B. However, it is assumed that the security rule list 42 shown in FIG. 12(b) has been created before the processing in this flowchart is executed.

In S51, the static analysis unit 33 obtains the source code 2. In S52, the static analysis unit 33 searches for violation descriptions in the source code 2 according to the security rule list 42. Note that a method of searching for a description that violates a predetermined rule can be realized by a publicly known technique. Then, in S53, the static analysis unit 33 outputs a search result list representing the search results.

FIG. 14 shows an example of a search result list representing the search results of the static analysis unit 33. In this embodiment, the source code 2 includes a main program whose file name is "main.c" and a subprogram whose file name is "sub.c."

As shown in FIG. 14(a), the search result list 43 includes, for each detected violation description, the file name where the violation was detected, the location where the violation was detected, the description related to the violation, and the rule where the violation was detected. represents the rule number that identifies the rule, the content of the detected violation, and the priority of the rule in which the violation was detected. The priority is set with reference to the security rule list 42 shown in FIG. 12(b). For example, in line 12 of the main program, a violation in which the denominator of division becomes zero is detected. This violation corresponds to the violation with the highest priority (ie, level 3 violation), as shown in FIG. 12(b). Therefore, the static analysis unit 33 associates "level 3" with this violation description. In this way, the static analysis unit 33 detects violation descriptions from the source code 2, and associates each detected violation description with a priority indicating the severity of the security risk. As a result, a search result list 43 is obtained.

The static analysis unit 33 may create a search result list 44 showing an overview of search results, as shown in FIG. 14(b). The search result list 44 indicates, for each file, the number of lines of source code searched, the total number of descriptions in which violations were detected, and the number of descriptions in which violations were detected for each priority. For example, the search results for the main program with the file name "main.c" indicate that 3, 2, and 15 level 3, level 2, and level 1 violations were detected, respectively.

The determination unit 14B determines a policy for dealing with high-risk descriptions in the source code, based on the analysis results by the structure analysis unit 13 and the search results by the static analysis unit 33. In other words, the determination unit 14B determines the response plan based on the combination of the evaluation score calculated by the structural analysis unit 13 and the priority used by the static analysis unit 33.

FIG. 15 is a flowchart illustrating an example of processing by the determination unit 14B. It is assumed that before executing the processing in this flowchart, the analysis result list 23 has been created by the structure analysis section 13 and the search result list 43 has been created by the static analysis section 33.

In S61, the determination unit 14B obtains the analysis result list created by the structure analysis unit 13. At this time, the determination unit 14B obtains an analysis result list (for example, the analysis result list 23 shown in FIG. 6A) in which evaluation points are assigned to each program module. In S62, the determination unit 14B obtains the search result list created by the static analysis unit 33. At this time, the determination unit 14B obtains a search result list (for example, the search result list 43 shown in FIG. 14A) in which a priority is set for each violation description. In S63, the determination unit 14B selects a violation description from the search result list.

In S64, the determination unit 14B identifies the program module that includes the violation description selected in S63, and checks the evaluation score assigned to that program module. The correspondence between the violation description and the program module may be detected based on the position within the source code. For example, the first violation description shown in FIG. 14(a) is located on the 12th line of the source code. On the other hand, the first function "main()" shown in FIG. 6(a) is located on the 10th line of the source code. Therefore, it is determined that this function corresponds to the first violation description shown in FIG. 14(a).

In S65, the determination unit 14B determines whether the priority of the violation description selected in S63 is "Level 3: High priority" and the evaluation score of the program module including the violation description exceeds "2". Determine. Then, when the priority is "Level 3: High Priority" and the evaluation score exceeds "2", the determination unit 14B, in S66, displays the violation description/program module as shown in FIG. 16(a). Add to other language replacement list 45. The other language replacement list 45 is a list for registering violation descriptions/program modules that need to be replaced with other languages. On the other hand, when the priority of the selected violation description is "Level 2: Medium priority" or "Level 1: Low priority", or the evaluation score of the program module containing the violation description is "2" or less. If so, the determination unit 14B adds the violation description/program module to the other processing list 46 shown in FIG. 16(b) in S67. The other processing list 46 is a list for registering violation descriptions/program modules that should execute processing other than processing for replacing with another language.

In S68, the determining unit 14B checks whether any violation descriptions for which the processes of S64 to S67 have not been executed remain in the search result list. If there are violation descriptions that have not been processed in S64 to S67 remaining in the search result list, the process of the determination unit 14B returns to S63. That is, the next violation description is selected from the search result list. Thereafter, the processes of S64 to S67 are executed for the newly selected violation description. Then, when the processes of S64 to S67 are executed for all violation descriptions registered in the search result list, the process of the determination unit 14B ends. In this way, the other language replacement list 45 and the other processing list 46 are created.

For example, it is assumed that the analysis result list 23 shown in FIG. 6(a) and the search result list 43 shown in FIG. 14(a) are provided to the determination unit 14B. Then, the determination unit 14B executes the processes of S64 to S67 for each violation description registered in the search result list 43.

In this case, for example, the priority of the violation description on the 12th line is level 3, and the evaluation score of the program module (function: main()) that includes the violation description is "3". Therefore, this violating description/program module is added to the other language replacement list 45, as shown in FIG. 16(a). Furthermore, the priority of the violation description on the 203rd line is level 2, and the evaluation score of the program module (function: aaa()) that includes the violation description is "1". Therefore, this violation description/program module is added to the other processing list 46, as shown in FIG. 16(b). Note that the other language replacement list 45 is used as a policy for dealing with violation descriptions/program modules that have complex program structures and are associated with the highest priority (level 3) from the perspective of security risks. , is an example of information instructing to replace the first language (C/C++) with a second language (Rust) that is more reliable.

The operations of the source code modification device 4 and the testing device 5 are substantially the same in the embodiment shown in FIG. 1 and the second embodiment shown in FIG. That is, the source code modification device 4 modifies the source code based on the information output from the source code modification support device 1B, and the testing device 5 tests the modified source code.

In this manner, in the second embodiment of the present invention, descriptions (or program modules) that violate coding rules and are determined to have a high risk from the metrics perspective are extracted. Therefore, compared to the embodiment shown in FIG. 1, more important descriptions or program modules can be modified more efficiently.

<Third embodiment>
In the embodiments shown in FIGS. 1 to 8, high-risk program modules are extracted using metrics that analyze the structure of source code. Furthermore, in the second embodiment shown in FIGS. 10 to 16, program modules with high risk are extracted using secure coding rules in addition to metrics. The extracted program module is then replaced with a highly reliable language (for example, Rust).

However, even if the description does not violate the secure coding rules or has no problem from the perspective of metrics, there are some descriptions that are preferably replaced with a highly reliable language. Therefore, in the third embodiment, templates are created for code styles in which vulnerabilities may occur and code styles in which countermeasures for vulnerabilities have been taken. Then, the source code modification support device uses this template to extract from the source code a description that is preferably replaced with a highly reliable language.

FIG. 17 shows an example of a source code modification support device according to the third embodiment of the present invention. A source code modification support device 1C according to the third embodiment includes a template creation section 51, a template 52, a template search section 53, and a determination section 54. The source code 2 is then given to the source code modification support device 1C. Source code 2 is a pre-compiled program code written in a predetermined programming language. In this embodiment, it is assumed that the source code 2 is written in C language (or C++).

Registered in the template 52 are code styles in which vulnerabilities may occur in source code written in C/C++ and code styles in which security measures are taken in C/C++. In this embodiment, as shown in FIG. 18, an external function, a specific function, a loop+array operation, a loop+pointer operation, etc. are registered in the template 52. External functions represent functions created by the user. Since functions created by users may be vulnerable, they are preferably registered in the template 52. The specific function represents a function defined in secure coding rules (such as CERT-C) and designed to allow safe use of the C/C++ language. As an example, the specific function corresponds to a C/C++ standard function that is protected against buffer overflows. The loop+array operation corresponds to, for example, the process of copying character data one byte at a time to an array. The loop+pointer operation corresponds to, for example, a process of copying character data one byte at a time to an area indicated by an address. Note that "code styles in which vulnerabilities may occur in source code written in C/C++" may be listed by the worker who modifies the source code 2, for example, based on past experience or track record. .

The template creation unit 51 creates the template 52 described above. Note that the template creation unit 51 is realized, for example, by an operator who modifies the source code 2 operating a computer.

The template search unit 53 searches the source code 2 using the template 52. Specifically, the template search unit 53 extracts a program module including the code style registered in the template 52 from the source code 2.

FIG. 19 is a flowchart showing an example of the processing of the template search unit 53. The processing in this flowchart is executed when the source code 2 is given to the source code modification support device 1C. However, it is assumed that the template 52 shown in FIG. 18 has been created before the processing in this flowchart is executed.

In S71, the template search unit 53 obtains the source code 2. In S72, the template search unit 53 extracts a program module that includes a code style that matches the template 52 from the source code 2. At this time, the template search unit 53 preferably detects the position (line number) where the extracted program module is written. Then, in S73, the template search unit 53 outputs a search result list representing the search results.

20 and 21 show an example of a search result list representing the search results by the template search unit 53. Although not shown in FIGS. 20 and 21, the search result list may include information indicating the location of the extracted program module, as shown in FIG. 6 or 14.

In the embodiment shown in FIG. 20A, an external function (ex_strcpy) is detected from the source code 2 based on the template, and a program module including the external function is registered in the search result list 81. The template search unit 53 extracts, from among the functions created by the user, a program module that includes a function that conforms to the following format without any violation.
Format: Function name (storage destination address, storage destination size, read source address)
Note that the function extracted in this example prevents a buffer overrun by not exceeding a specified storage destination size when writing data to a storage destination address.

In the example shown in FIG. 20(b), a specific function (strcpy_s) is detected from the source code 2, and a program module including the specific function is registered in the search result list 81. This copy function also has parameters (dest, size, src) specified to avoid buffer overruns.

In the example shown in FIG. 21A, a description related to "loop + array operation" is detected from the source code 2, and a program module including the detected description is registered in the search result list 81. For example, a while statement or a for statement is detected as a loop process. As the array processing, a description expressing "dest[n]=data" is detected. In this example, a description for copying character data one byte at a time to an array is detected.

In the example shown in FIG. 21(b), a description related to "loop + pointer operation" is detected from the source code 2, and a program module including the detected description is registered in the search result list 81. For example, a while statement or a for statement is detected as a loop process. As the array processing, a description representing "*dest=data" is detected. In this embodiment, a description for copying character data one byte at a time to the area indicated by the specified address is detected.

The determination unit 54 determines whether each program module extracted from the source code 2 by the template search unit 53 should be replaced with another language. That is, it is determined whether each program module registered in the search result list 81 is to be replaced with another language.

FIG. 22 is a flowchart illustrating an example of processing by the determination unit 54. The processing in this flowchart is executed after one or more program modules are extracted from the source code 2 by the template search unit 53. That is, it is assumed that the search result list 81 has been created before the processing in this flowchart is executed.

In S81, the determination unit 54 obtains the search result list created by the template search unit 53. In S82, the determination unit 54 selects a program module from the search result list. In S83, the determination unit 54 determines the priority based on the ease of replacing the selected program module with another language. The ease of replacing with another language is determined by, for example, the complexity of the program module or the degree of coupling of written contents.

23 and 24 show a state in which priorities are assigned to each program module registered in the search result list shown in FIGS. 20 and 21. In this example, the degree of coupling (or ease of replacing with other languages) of a program module is expressed in three levels. Furthermore, the priority of the program module is set with respect to the degree of coupling. For example, in the example shown in FIG. 23, the degree of coupling of the external function ex_strcpy is medium level (level 2) and is given medium level (level 2) priority. Further, the specific function strcpy_s has a low level of connectivity (level 1) and is given a high level (level 3) of priority.

In S84, the determination unit 54 determines processing for the selected program module according to the priority of the program module. When the priority is "level 3 (high)", the determination unit 54 determines that it is easy to replace the selected program module with another language. In this case, the determination unit 54 adds the program module to the other language replacement list in S85. When the priority is "level 2 (medium)", the determination unit 54 determines that it is somewhat difficult to replace the selected program module with another language. In this case, the determination unit 54 adds the program module to the other processing list in S86. When the priority is "level 1 (low)", the determination unit 54 determines that it is difficult to replace the selected program module with another language. In this case, the processes of S85 and S86 are skipped.

In S87, the determination unit 54 checks whether there are any program modules remaining in the search result list for which the processes in S83 to S86 have not been executed. If a program module that has not undergone the processes of S83 to S86 remains in the search result list, the process of the determination unit 54 returns to S82. That is, the next program module is selected from the search result list. Thereafter, the processes of S83 to S86 are executed for the newly selected program module. Then, when the processes of S83 to S86 are executed for all program modules registered in the search result list, the process of the determination unit 54 ends. As a result, a foreign language replacement list and a foreign processing list are created.

In this way, the source code modification support device 1C uses the template 52 to extract program modules that are preferably replaced with a highly reliable language from the source code 2. The results obtained by the source code modification support device 1C are then given to the source code modification device 55.

The operation of source code modification device 55 is substantially the same as source code modification device 4 shown in FIG. That is, the source code modification device 55 modifies the source code based on the information output from the source code modification support device 1C. For example, the source code modification device 55 replaces the program module registered in the other language replacement list generated by the source code modification support device 1C with RUST. Thereafter, the modified source code may be tested using the testing device 5, similar to the procedure shown in FIG.

<Variation>
FIG. 25 shows a variation of an embodiment of the invention. In a variation of the embodiment of the present invention, a source code modification support device 1C shown in FIG. 17 is provided on the input side of the source code modification support device 1 shown in FIG. 1 or the source code modification support device 1B shown in FIG. In the following description, the source code modification support device 1 shown in FIG. 1 or the source code modification support device 1B shown in FIG. 10 may be referred to as "source code modification support device 1/1B."

A source code modification device 55 shown in FIG. 17 is provided between source code modification support device 1C and source code modification support device 1/1B. Further, the source code modification device 4 and testing device 5 shown in FIG. 1 or 10 are provided on the output side of the source code modification support device 1/1B. According to this configuration, in addition to replacing high-risk program modules with reliable languages based on metrics and/or secure coding rules, code styles that can lead to vulnerabilities and countermeasures for vulnerabilities are Program modules related to the current code style are also replaced with more reliable languages.

In the configuration shown in FIG. 25, the source code modification device 4 uses not only the foreign language replacement list generated by the source code modification support device 1/1B but also the foreign language replacement list generated by the source code modification support device 1C. If the source code is to be modified based on the source code, it is not necessary to provide the source code modification device 55. Further, although the source code modification support device 1C is provided on the input side of the source code modification support device 1/1B in FIG. 25, it may be provided on the output side of the source code modification support device 1/1B. Furthermore, the source code modification support device 1/1B and the source code modification support device 1C may constitute one source code modification support device.

<Hardware configuration>
FIG. 26 shows an example of the hardware configuration of the source code modification support device 1, 1B, or 1C. The source code modification support device 1, 1B, or 1C is realized by a computer 200 including a processor 201, a memory 202, a storage device 203, an input/output device 204, a recording medium reading device 205, and a communication interface 206.

Processor 201 controls the operation of source code modification support device 1, 1B, or 1C by executing a modification support program stored in storage device 203. In the source code modification support device 1, the modification support program includes a program code that describes the procedures of the flowcharts shown in FIGS. 3, 5, and 7. Therefore, when the processor 201 executes this program, the functions of the metrics rule list creation section 11, metrics rule list acquisition section 12, structure analysis section 13, and determination section 14 shown in FIG. 1 are provided. Furthermore, in the source code modification support device 1B, the modification support program includes program codes that describe the procedures of the flowcharts shown in FIGS. 3, 5, 13, and 15. Therefore, by the processor 201 executing this program, the metrics rule list creation section 11, the metrics rule list acquisition section 12, the structure analysis section 13, the security rule list creation section 31, the security rule list acquisition section 32, shown in FIG. The functions of the static analysis section 33 and the determination section 14B are provided. Furthermore, in the source code modification support device 1C, the modification support program includes a program code that describes the procedures of the flowcharts shown in FIGS. 19 and 22. Therefore, when the processor 201 executes this program, the functions of the template search unit 53 and determination unit 54 shown in FIG. 17 are provided. Memory 202 is used as a work area for processor 201. The storage device 203 stores the above-mentioned modification support program and other programs.

The input/output device 204 includes input devices such as a keyboard, a mouse, a touch panel, and a microphone. In addition, the input/output device 204 includes an output device such as a display device and a speaker. The recording medium reading device 205 can acquire data and information recorded on the recording medium 210. The recording medium 210 is a removable recording medium that can be attached to and detached from the computer 200. Further, the recording medium 210 is realized by, for example, a semiconductor memory, a medium for recording signals by optical action, or a medium for recording signals by magnetic action. Note that the modification support program may be provided to the computer 200 from the recording medium 210. Communication interface 206 provides the ability to connect to a network. Note that when the modification support program is stored in the program server 220, the computer 200 may acquire the modification support program from the program server 220.

Computer 200 shown in FIG. 26 may provide the functions of source code modification device 4, source code modification device 55, and testing device 5 in addition to the functions of source code modification support devices 1, 1B, and 1C. Further, the source code modification support devices 1, 1B, 1C, the source code modification devices 4, 55, and the testing device 5 may be realized by separate computers.

1, 1B, 1C Source code modification support device 2 Source code 3 Metrics list 4 Source code modification device 5 Test device 11 Metrics rule list creation section 12 Metrics rule list acquisition section 13 Structural analysis section 14, 14B Judgment section 21 Evaluation value list 22 Metric rule list 23 Analysis result list 24 Analysis result list 25 representing an overview of analysis results Other language replacement list 26 Other processing list 30 Secure coding rules 31 Security rule list creation unit 32 Security rule list acquisition unit 33 Static analysis unit 41 Priority List 42 Security rule list 43 Search result list 44 Search result list 45 showing an overview of search results Other language replacement list 46 Other processing list 51 Template creation section 52 Template 53 Template search section 54 Judgment section 200 Computer 201 Processor 202 Memory 203 Storage device 204 Input/output device 205 Recording medium reading device 206 Communication interface 210 Recording medium 220 Program server

Claims (7)

Obtain a metrics rule list created by assigning a reference value for determining program complexity and an evaluation value corresponding to program complexity to each of multiple metrics items related to source code structure analysis. a metrics rule list acquisition unit,
For each program module in the source code written in the first language, it is determined whether or not it violates the standard value corresponding to each metrics item registered in the metrics rule list, and the standard value is violated. a structural analysis unit that calculates an evaluation score representing the sum of evaluation values corresponding to the metrics items being evaluated;
a determination unit that determines a response policy for each program module based on the evaluation score calculated by the structure analysis unit;
A source code modification support device comprising: Information instructing the determination unit to replace a program module whose evaluation score calculated by the structure analysis unit exceeds a predetermined threshold with a second language that is more reliable than the first language. The source code modification support device according to claim 1, wherein the source code modification support device outputs the following. The source code correction according to claim 2, wherein in the metrics rule list, a metrics item that poses a greater security risk when the description of a program module violates a standard value is given a higher evaluation point. Support equipment. Further comprising a static analysis unit that extracts, in the source code written in the first language, a violation description that violates a predetermined coding rule that must be followed when writing the source code,
According to claim 1, the determination unit determines a response policy for each program module including the violation description extracted by the static analysis unit, based on the evaluation score calculated by the structural analysis unit. Source code modification support device described. Obtaining a template in which at least one of a code style in which vulnerabilities may occur in source code written in the first language or a code style in which countermeasures related to vulnerabilities are taken in the first language is registered. , a template search unit that extracts a program module including a code style registered in the template from the source code;
The source code modification support device according to claim 1, further comprising a second determination unit that determines whether to replace the program module extracted by the template search unit with the second language. . Obtain a metrics rule list created by assigning a reference value for determining program complexity and an evaluation value corresponding to program complexity to each of multiple metrics items related to source code structure analysis. a metrics rule list acquisition unit,
For each program module in the source code written in the first language, it is determined whether or not it violates the standard value corresponding to each metrics item registered in the metrics rule list, and the standard value is violated. a structural analysis unit that calculates an evaluation score representing the sum of evaluation values corresponding to the metrics items being evaluated;
a determination unit that determines whether each program module should be replaced with a second language that is more reliable than the first language based on the evaluation score calculated by the structure analysis unit;
a conversion unit that converts a program module determined by the determination unit to be replaced with the second language into a description in the second language;
A source code modification system. Obtain a metrics rule list created by assigning a reference value for determining program complexity and an evaluation value corresponding to program complexity to each of multiple metrics items related to source code structure analysis. death,
For each program module in the source code written in the first language, it is determined whether or not it violates the standard value corresponding to each metrics item registered in the metrics rule list, and the standard value is violated. Calculate the evaluation score that represents the sum of the evaluation values corresponding to the metrics items that are
A source code modification support method characterized by determining a response policy for each program module based on the evaluation score.

Images