Source code modification support device and source code modification support method
The source code modification support device efficiently addresses the challenge of rewriting vulnerable sections in large-scale programs by prioritizing and automating the conversion of high-risk code to more reliable languages, thereby reducing the effort and cost associated with securing software.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- FUJI ELECTRIC CO LTD
- Filing Date
- 2022-07-21
- Publication Date
- 2026-06-02
AI Technical Summary
Large-scale programs with software vulnerabilities require significant effort to rewrite vulnerable sections in more reliable programming languages, as the number of vulnerable places increases, making the task time-consuming.
A source code modification support device that assigns priorities to secure coding rules, identifies violation descriptions, and determines appropriate actions based on these priorities, facilitating efficient replacement or correction of vulnerable code sections with more reliable languages.
Reduces the effort required to replace or correct vulnerable code sections by prioritizing high-risk areas for language conversion, ensuring efficient and targeted security enhancements in large-scale programs.
Smart Images
Figure 0007868437000001 
Figure 0007868437000002 
Figure 0007868437000003
Abstract
Description
Technical Field
[0001] The present invention relates to an apparatus and a method for assisting in the operation of replacing descriptions in source code with descriptions in other languages.
Background Art
[0002] With the increasing opportunities to connect to a network, cases where software vulnerabilities are targeted by malicious third parties and malfunctions occur are also increasing. For this reason, at the development stage, by analyzing source code based on predetermined secure coding rules, work is being done to discover software vulnerabilities. Thereby, the security of software is ensured. For example, in fields such as in-vehicle devices, industrial devices, and medical devices, 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.
[0003] In addition, programming languages that reduce software vulnerabilities are becoming widespread. For example, Rust is a language that guarantees memory safety and is attracting attention as one of the languages to replace the C language or C++.
[0004] Note that a source program analysis apparatus that points out errors in the execution processing order of a source program has been proposed (for example, Patent Document 1). Also, a source code conversion apparatus that converts source code described in a certain programming language into source code in another programming language has been proposed (for example, Patent Document 2). Furthermore, an apparatus that supports program modification or debugging has been proposed (for example, Patent Documents 3 to 4).
Prior Art Documents
Patent Documents
[0005] [Patent Document 1] Japanese Patent Publication No. 2006-236042 [Patent Document 2] Japanese Patent Publication No. 2010-140408 [Patent Document 3] Japanese Patent Publication No. 2021-192201 [Patent Document 4] Japanese Patent Publication No. 2009-104252 [Overview of the project] [Problems that the invention aims to solve]
[0006] As mentioned above, highly reliable programming languages such as Rust are becoming more widespread. On the other hand, there is a demand to continue using existing software products as much as possible in order to reduce the cost and time required for program development. For this reason, in order to address vulnerabilities in existing software, static analysis tools are sometimes used to identify vulnerable parts, and only those identified parts are rewritten in a highly reliable language.
[0007] However, in large-scale programs, the number of places containing vulnerabilities also increases. Therefore, rewriting all vulnerable sections in a highly reliable language would be a time-consuming task.
[0008] One aspect of the present invention is to reduce the effort required to replace a portion of source code written in one language with code written in another language. [Means for solving the problem]
[0009] A source code modification support device according to one aspect of the present invention includes: a rule list acquisition unit that acquires a rule list created by assigning priority to each rule that must be followed when writing source code; a static analysis unit that searches for violation descriptions in source code written in a first language that violate the rules described in the rule list, and associates the priority assigned to the rule violated by the violation description with each violation description based on the rule list; and a determination unit that determines a course of action for each violation description found by the static analysis unit based on the associated priority. [Effects of the Invention]
[0010] According to the above-described embodiment, the effort required to replace a portion of source code written in one language with code written in another language can be reduced. [Brief explanation of the drawing]
[0011] [Figure 1] This figure shows an example of a source code modification support device according to an embodiment of the present invention. [Figure 2] This figure shows an example of secure coding rules. [Figure 3] This flowchart shows an example of the processing in the rule list creation section. [Figure 4] This figure shows examples of priority lists and security rule lists. [Figure 5] This flowchart shows an example of the processing performed by the static analysis unit. [Figure 6] This figure shows an example of a search results list representing the results from the static analysis unit. [Figure 7] This flowchart shows an example of the processing performed by the determination unit. [Figure 8] This figure shows examples of a list for replacing words with other languages and a list for processing words with other languages. [Figure 9] This flowchart shows the variations in the processing of the judgment unit. [Figure 10]It is a flowchart showing an example of processing by a source code correction device and a test device. [Figure 11] It is a diagram showing an example of the hardware configuration of a source code correction support device.
Embodiment for Carrying Out the Invention
[0012] FIG. 1 shows an example of a source code correction support device according to an embodiment of the present invention. The source code correction support device 1 according to the embodiment of the present invention searches for violation descriptions from the source code 2 based on the secure coding rule 3 and outputs information representing a countermeasure policy for each violation description.
[0013] The source code 2 is program code before compilation, described in a predetermined programming language. Although not particularly limited, in this example, it is assumed that the source code 2 is described in C language or C++. Also, the source code 2 may be program code used as an existing software product.
[0014] The secure coding rule 3 is information in which the rules that must be observed when describing the source code are listed, and is used when the source code correction support device 1 analyzes the source code 2. In this example, the source code correction support device 1 uses an existing coding rule as the secure coding rule 3. For example, CERT, MISRA, or AUTOSAR is used as the secure coding rule 3. As an example, a part of the CERT-C / C++ coding standard convention used in the analysis of code described in C / C++ is shown in FIG. 2.
[0015] As shown in FIG. 1, the source code correction support device 1 includes a rule list creation unit 11, a rule list acquisition unit 12, a static analysis unit 13, and a determination unit 14. Note that the source code correction support device 1 may include other functions or devices not shown in FIG. 1.
[0016] The rule list creation unit 11 is given secure coding rules 3. Here, secure coding rules 3 represent one or more rules that must be followed when writing source code, as described above. The rule list creation unit 11 then creates a security rule list by assigning a priority to each rule listed as secure coding rules 3. The rule list creation unit 11 is implemented, for example, by a worker modifying source code 2 operating a computer.
[0017] Figure 3 is a flowchart showing an example of the processing performed by the rule list creation unit 11. This flowchart is executed, for example, when source code 2 is provided to the source code modification support device 1. However, the rule list creation unit 11 may also execute the flowchart shown in Figure 3 before source code 2 is provided to the source code modification support device 1.
[0018] In S1, the rule list creation unit 11 creates a priority list related to the handling policy when modifying the source code 2. The priority list 21, as shown in Figure 4(a), represents the definition of the priority to be assigned to each rule provided as secure coding rule 3. 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 or more levels of priority may also be set.
[0019] The response policy describes how to deal with descriptions that violate the rule in question. In this embodiment, the policies shown in Figure 4(a) are set according to priority. Specifically, for descriptions that violate the rule assigned the highest priority level 3, the policy is to "replace with a description in another language." For descriptions that violate the rule assigned the second highest priority level 2, the policy is to "recommend replacing with a description in another language." For descriptions that violate the rule assigned the lowest priority level 1, the policy is to "correct based on the prescribed policy."
[0020] In S2, the rule list creation unit 11 obtains the secure coding rules 3 given to the source code modification support device 1. In S3, the rule list creation unit 11 creates a security rule list by assigning a priority to each rule that must be followed when writing source code. In this embodiment, by assigning the priority shown in Figure 4(a) to each rule shown in Figure 2, the security rule list 22 shown in Figure 4(b) is obtained.
[0021] For example, if the source code contains a statement that violates the rule identified as "INT32-C," which states "Ensure that signed integer operations do not cause overflow," a serious failure is likely to occur. Therefore, this rule is assigned a high priority of "3." The same applies to the rules identified as "INT33-C" and "EXP33-C." Also, if the source code contains a statement that violates the rule identified as "ARR32-C," which states "Ensure that the size argument of a variable-length array is within an appropriate range," some failure may occur, but it is not considered likely to be a serious failure. Therefore, this rule is assigned an intermediate priority of "2." On the other hand, even if the source code contains a statement that violates the rule identified as "MSC05-C," which states "Do not directly manipulate the value of type time_t," it is considered unlikely to be a serious failure. Therefore, this rule is assigned a low priority of "1."
[0022] The priority assigned to each rule may be determined, for example, by the worker modifying source code 2. In this case, the security rule list 22 shown in Figure 4(b) is created by this worker operating a computer. The created security rule list 22 is stored in a memory (not shown) of the source code modification support device 1.
[0023] The rule list acquisition unit 12 acquires the security rule list 22 created by the procedure shown in Figure 3. In this embodiment, the rule list acquisition unit 12 reads the security rule list 22 shown in Figure 4(b) from the memory of the source code modification support device 1.
[0024] The static analysis unit 13 searches for violation descriptions in the source code 2 based on the security rule list 22 obtained by the rule list acquisition unit 12. That is, the static analysis unit 13 searches for violation descriptions in the source code 2 that violate the rules listed in the security rule list 22.
[0025] Figure 5 is a flowchart showing an example of the processing performed by the static analysis unit 13. This flowchart is executed when the source code 2 is provided to the source code modification support device 1. However, it is assumed that the security rule list 22 shown in Figure 4(b) has been created before this flowchart is executed.
[0026] In S11, the static analysis unit 13 obtains the source code 2. In S12, the static analysis unit 13 searches for violation descriptions in the source code 2 according to the security rule list 22 created by the procedure shown in Figure 3. The method for searching for descriptions that violate predetermined rules is implemented by publicly known technology. Then, in S13, the static analysis unit 13 outputs a search results list representing the search results.
[0027] Figure 6 shows an example of a search result list representing the search results of the static analysis unit 13. In this embodiment, source code 2 includes a main program named "main.c" and a subprogram named "sub.c".
[0028] As shown in Figure 6(a), the search result list 23 displays, 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, the rule number identifying the rule on which the violation was detected, the content of the detected violation, and the priority of the rule on which the violation was detected. The priority is set by referring to the security rule list 22 shown in Figure 4(b). For example, a violation where the denominator of a division is zero is detected on line 12 of the main program. As shown in Figure 4(b), this violation corresponds to the highest priority violation (i.e., a level 3 violation). Therefore, the static analysis unit 13 associates "level 3" with this violation description. In this way, the static analysis unit 13 detects violation descriptions from the source code 2 and associates a priority representing the severity of the security risk with each detected violation description. This results in the search result list 23.
[0029] The static analysis unit 13 may create a search result list 24 that represents an overview of the search results, as shown in Figure 6(b). The search result list 24 shows, 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 level. For example, the search results for the main program named "main.c" show that 3 violations of level 3, 2 violations of level 2, and 15 violations of level 1 were detected.
[0030] The determination unit 14 determines the appropriate course of action for each violation description based on the search results obtained by the static analysis unit 13. Specifically, the determination unit 14 determines the appropriate course of action for each violation description detected by the static analysis unit 13 based on the associated priority.
[0031] Figure 7 is a flowchart showing an example of the processing performed by the determination unit 14. It is assumed that the search result list 23 has been created by the static analysis unit 13 before the processing shown in this flowchart is executed.
[0032] In S21, the determination unit 14 obtains the search result list created by the static analysis unit 13. At this time, it obtains a search result list in which a priority is set for each violation description (for example, the search result list 23 shown in Figure 6(a)). In S22, the determination unit 14 selects a violation description from the search result list. In S23, the determination unit 14 determines whether the priority of the selected violation description is "Level 3: High Priority".
[0033] If the priority of the selected violation description is "Level 3: High Priority," the determination unit 14 adds the violation description to the other-language replacement list 25 shown in Figure 8(a) in S24. The other-language replacement list 25 is a list for registering violation descriptions that need to be replaced with another language. On the other hand, if the priority of the selected violation description is "Level 2: Medium Priority" or "Level 1: Low Priority," the determination unit 14 adds the violation description to the other-processing list 26 shown in Figure 8(b) in S25. The other-processing list 26 is a list for registering violation descriptions that should be processed in a way other than replacement with another language.
[0034] In S26, the determination unit 14 checks if there are any violation descriptions remaining in the search results list that have not undergone the processing in S23 to S25. If there are any violation descriptions remaining in the search results list that have not undergone the processing in S23 to S25, the determination unit 14 returns to S22. That is, the next violation description is selected from the search results list. After this, the processing in S23 to S25 is executed for the newly selected violation processing. Then, when the processing in S23 to S25 has been executed for all violation descriptions registered in the search results list, the determination unit 14 terminates. In this way, the other language replacement list 25 and the other processing list 26 are created.
[0035] For example, suppose the search result list 23 shown in Figure 6(a) is given to the determination unit 14. The determination unit 14 then executes the processes S23 to S25 for each violation description registered in the search result list 23. In this case, the priority of the violation description on line 12 and the violation description on line 103 is level 3. Therefore, these violation descriptions are added to the other language replacement list 25. On the other hand, the priority of the violation description on line 203 is level 2, and the priority of the violation description on line 303 is level 1. Therefore, these violation descriptions are added to the other processing list 26. This yields the other language replacement list 25 shown in Figure 8(a) and the other processing list 26 shown in Figure 8(b). The other language replacement list 25 is an example of information that instructs the system to replace the violation description with the highest priority (level 3) with a second language (Rust) that is more reliable than the first language (C / C++).
[0036] Note that the procedure shown in Figure 7 is just one example, and the embodiments of the present invention are not limited to this procedure. For example, in the example shown in Figure 9, the processes S31 to S32 are executed instead of S23 shown in Figure 7. That is, in S31, the determination unit 14 determines whether the priority of the selected violation description is "Level 2: Medium priority" or "Level 3: High priority". If the priority of the selected violation description is "Level 2: Medium priority" or "Level 3: High priority", in S32, the determination unit 14 checks the coupling degree of the functions related to the selected violation description. If the coupling degree of the functions related to the violation description is low, the determination unit 14 determines that it is easy to replace the violation description with a description in another language, and in S24, it adds the violation description to the other language replacement list 25. On the other hand, if the priority of the selected violation description is "Level 1: Low priority", or if the coupling degree of the functions related to the violation description is high, the determination unit 14 adds the violation description to the other processing list 26 in S25. The degree of coupling of a function indicates, for example, how much impact modifying that function will have on other parts of the code.
[0037] In this way, the source code modification support device 1 extracts violation descriptions from the source code 2 based on the secure coding rules 3. At this time, each violation description is assigned a priority corresponding to the severity of the security risk (or the degree of need to replace it with a more reliable programming language). The source code modification support device 1 then creates the other language replacement list 25 and the other processing list 26 by grouping each violation description by referring to this priority. After this, the other language replacement list 25 and the other processing list 26 are provided to the source code modification device 4 shown in Figure 1.
[0038] The source code modification device 4 modifies the source code 2 based on the other language substitution list 25 and other processing list 26 created by the source code modification support device 1. Then, the test device 5 performs operational verification by executing the source code 2 modified by the source code modification device 4. The source code modification device 4 and the test device 5 are implemented, for example, by the worker modifying the source code 2 operating a computer.
[0039] Figure 10 is a flowchart showing an example of processing by the source code modification device 4 and the test device 5. In this embodiment, in S41, the source code modification device 4 acquires the source code 2. In addition, in S42 and S45, the source code modification device 4 acquires the other language replacement list 25 and the other processing list 26 created by the source code modification support device 1, respectively.
[0040] The processing in S43-S44 is performed for each violation description registered in the other-language replacement list 25. That is, in S43, the source code correction device 4 replaces the violation description with a description in another language. For example, when source code 2 is written in C language, the violation description is replaced with a description in Rust language. In this case, the worker correcting source code 2 may manually rewrite the code using the computer that implements the source code correction device 4. Alternatively, if the source code correction device 4 has a function to convert from C language to Rust language, the source code correction device 4 replaces the violation description with a description in Rust language. In this case, the source code correction device 4 operates as a conversion unit that converts the violation description determined by the determination unit 14 to be replaced with a description in another language into a Rust description. Note that it is not easy to convert the entire program code to another language by software processing, but it is possible to convert some of the descriptions to another language using existing technology.
[0041] In S44, the test device 5 compiles and executes the description that has been replaced with another language. That is, it tests whether the violating description has been correctly replaced with another language. The test results are then fed back to the source code modification device 4. At this point, if the violating description has not been correctly replaced with another language, the source code modification device 4 further modifies that description. As a result, each violating description registered in the other language replacement list 25 is correctly replaced with another language.
[0042] The processing in S46-S47 is performed for each violation description registered in the other processing list 26. That is, in S46, the source code correction device 4 corrects the violation description in the language of the source code. For example, if source code 2 is written in C language, the content of the violation description is corrected in C language. At this time, the worker correcting source code 2 may manually correct the code using the computer that implements the source code correction device 4. Alternatively, the source code correction device 4 may output a report indicating that the violation description has not been corrected without actually correcting the violation description.
[0043] In S47, the test device 5 compiles and executes the modified description. That is, it tests whether the violating description has been correctly corrected. The test results are then fed back to the source code correction device 4. If the violating description has not been correctly corrected, the source code correction device 4 further corrects the description. This corrects each violating description registered in the other processing list 26. Note that if the violating description is not corrected in S46, the process in S47 does not need to be executed.
[0044] In S48, the test device 5 combines the descriptions replaced with other languages and the modified descriptions into source code 2. Then, the test device 5 tests the program containing the descriptions replaced with other languages and the modified descriptions.
[0045] In this way, the source code modification support device 1 assigns a priority to each violation description detected in the source code, corresponding to the severity of the security risk (or the degree of need to replace it with a more reliable programming language). The source code modification support device 1 then outputs information representing the violation description to which the priority has been assigned. Therefore, even if the source code is large and contains many violation descriptions, the worker modifying the source code 2 can easily identify violation descriptions with a high severity of security risk. In other words, even in cases where it is difficult to replace all violation descriptions with descriptions in another language from the standpoint of cost or workload, violation descriptions with a high severity of security risk can be reliably replaced with descriptions in a more reliable programming language. This makes it possible to reduce the risk of unreliable existing programs even when there are constraints on cost or workload.
[0046] <Hardware Configuration> Figure 11 shows an example of the hardware configuration of the source code modification support device 1. The source code modification support device 1 is implemented by a computer 200 equipped with a processor 201, memory 202, storage device 203, input / output device 204, recording medium reader 205, and communication interface 206.
[0047] The processor 201 controls the operation of the source code modification support device 1 by executing a modification support program stored in the storage device 203. The modification support program includes program code that describes the steps in the flowcharts shown in Figures 3, 5, and 7. Therefore, when the processor 201 executes this program, the functions of the rule list creation unit 11, rule list acquisition unit 12, static analysis unit 13, and determination unit 14 shown in Figure 1 are provided. Memory 202 is used as the working area for the processor 201. Storage device 203 stores the modification support program and other programs mentioned above.
[0048] The input / output device 204 includes input devices such as a keyboard, mouse, touch panel, and microphone. The input / output device 204 also includes output devices such as a display device and speaker. The recording medium reader 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. The recording medium 210 can be implemented, for example, by semiconductor memory, a medium that records signals by optical action, or a medium that records signals by magnetic action. The correction support program may be provided from the recording medium 210 to the computer 200. The communication interface 206 provides the function of connecting to a network. When the correction support program is stored on the program server 220, the computer 200 may acquire the correction support program from the program server 220.
[0049] The computer 200 shown in Figure 11 may provide the functions of the source code modification support device 1, as well as the functions of the source code modification device 4 and the test device 5. Furthermore, the source code modification support device 1, the source code modification device 4, and the test device 5 may be implemented on separate computers. [Explanation of Symbols]
[0050] 1. Source code modification support device 2. Source code 3. Secure Coding Rules 4. Source Code Modification Device 5. Test equipment 11. Rule List Creation Section 12. Rule List Acquisition Section 13 Static analysis section 14 Judgment section 21 Priority List 22 Security Rule List 23, 24 Search Results List 25 List of replacements for other languages 26 Other Processing List
Claims
1. A rule list retrieval unit that retrieves a rule list created by assigning priority to each rule that must be followed when writing source code, A static analysis unit searches for violation descriptions in source code written in a first language that violate the rules listed in the rule list, and associates the priority assigned to the rule violated by each violation description with the rule list. A determination unit determines whether each violation description retrieved by the static analysis unit should be replaced with a second language that is more reliable than the first language, based on the associated priority. A source code modification support device equipped with the following features.
2. The determination unit outputs information instructing that the violation description with the highest priority be replaced with a second language that is more reliable than the first language, as the policy for dealing with the violation description. The source code modification support device according to feature 1.
3. The aforementioned priority represents the severity of the security risk arising from a violation statement that violates the rule to which that priority is assigned. The source code modification support device according to feature 1.
4. The aforementioned priority represents the degree to which it is necessary to replace a violation description that violates the rule to which that priority is assigned with a second language that is more reliable than the first language. The source code modification support device according to feature 1.
5. A rule list retrieval unit that retrieves a rule list created by assigning priority to each rule that must be followed when writing source code, A static analysis unit searches for violation descriptions in source code written in a first language that violate the rules listed in the rule list, and associates the priority assigned to the rule violated by each violation description with the rule list. A determination unit determines whether each violation description retrieved by the static analysis unit should be replaced with a second language that is more reliable than the first language, based on the associated priority. A conversion unit converts a violation description determined by the determination unit to be replaced in the second language into a description in the second language, A source code modification system equipped with the following features.
6. The computer obtains a list of rules created by assigning priority to each rule that must be followed when writing source code, The computer searches for violation statements in the source code written in the first language that violate the rules listed in the rule list, and, based on the rule list, associates each violation statement with the priority assigned to the rule that the violation statement violated. The computer determines, based on the associated priority, whether each violation description should be replaced with a second language that is more reliable than the first language. A method for assisting in the modification of source code, characterized by the features described herein.