Adaptively Generated Program Models

Abstract

A system and method for adaptively generating program models. A source code of a program to be tested for a code problem and a set of predefined patterns to be tested within the source code are received. Feature configuration data is generated by determining a set of features that correspond to the received set of predefined patterns. A set of program models is identified by selecting, for each feature in the set of features, a program model from among a plurality of program models that is optimized for that feature. A dynamic program model is constructed based on the identified set of program models, the dynamic program model adapted to resolve each of the patterns in the received set of predefined patterns. The source code is then tested for the code problem by extracting an instance of each of the set of predefined patterns from the dynamic program model.

Description

[Technical field]

[0001] The subject matter described relates generally to adaptively generating program models, and more particularly to building program models that improve effectiveness and performance by selectively providing models that are used to identify patterns through static analysis. [Background technology]

[0002] Many enterprises use source code management (SCM) systems (such as Git) to manage software projects. As code is written and changed, code issues (e.g., security vulnerabilities, code smells, coding standard violations, insecure flows, secrets, and the like) inevitably arise. Enterprises often apply automated testing processes that monitor the changing code to detect these issues as early as possible in the software development process. One example of an automated testing process is a static analysis tool (e.g., a static application security testing (SAST) tool) that can automatically detect code issues in the source code or compiled code of a software project. Static analysis tools are typically language and problem specific (e.g., based on the type of code issue). For example, some static analysis tools can detect secrets (e.g., hard-coded passwords) in source code, while others focus on detecting potential insecure flows and the like. As such, operators may employ a combination of static analysis tools to reduce the overall attack surface of their software. Each static analysis tool may analyze source code or compiled code and report detected code issues for further analysis (e.g., by a human security analyst). However, many existing static analysis tools require building large, resource-intensive models, which limits the usability of such tools. Summary of the Invention

[0003] Embodiments relate to systems and methods for dynamically constructing a program model having an appropriate level of granularity based on user-defined patterns to be extracted from the program model. In one embodiment, a system for adaptively generating a program model is provided, the system including: one or more processors; and a memory operatively coupled to the one or more processors, the memory including instructions that, when executed by the one or more processors, cause the one or more processors to: receive source code of a program to be tested for a code issue; receive a set of predefined patterns to be tested in the source code; generate feature configuration data by determining a set of features that correspond to the received set of predefined patterns; identify a set of program models by, for each feature in the set of features, selecting one or more program models from among a plurality of program models that are required to evaluate the feature; build a dynamic program model based on the set of identified program models, the dynamic program model adapted to resolve each of the patterns included in the received set of predefined patterns; and test the source code for the code issue by extracting an instance of each of the set of predefined patterns from the dynamic program model.

[0004] In another embodiment, a method for adaptively generating program models is provided, the method including: receiving source code of a program to be tested for a code problem; receiving a set of predefined patterns to be tested in the source code; generating feature configuration data by determining a set of features that correspond to the received set of predefined patterns; identifying a set of program models by, for each feature in the set of features, selecting from among a plurality of program models a program model that is optimized for that feature; building a dynamic program model based on the identified set of program models, the dynamic program model adapted to resolve each of the patterns included in the received set of predefined patterns; and testing the source code for the code problem by extracting an instance of each of the set of predefined patterns from the dynamic program model.

[0005] In yet another embodiment, the method may be embodied in computer executable program code and stored in a non-transitory storage device. [Brief description of the drawings]

[0006] [Figure 1] FIG. 1 is a block diagram illustrating a networked computing environment suitable for managing code for a software project, according to one embodiment. [Diagram 2] FIG. 1 is a block diagram illustrating an example program model, program model dependencies, and an analysis approach related to the program model. [Diagram 3] FIG. 2 is a block diagram illustrating the code scanner shown in FIG. 1 according to one embodiment. [Figure 4] 1 is a flow chart illustrating a method for adaptively generating a program model, according to one embodiment. [Diagram 5]2 is a block diagram illustrating an example computer suitable for use in the networked computing environment of FIG. 1, according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] The figures and the following description describe specific embodiments for purposes of illustration only. Those skilled in the art will readily recognize from the following description that alternative embodiments of the configurations and methods may be employed without departing from the principles described. Whenever possible, similar or similar reference numbers are used in the figures to indicate similar or similar functionality. When elements have a common numeral followed by a different letter, this indicates that the elements are similar or identical. Reference to numerals only generally refers to any one or any combination of such elements, unless the context indicates otherwise.

[0008] To analyze source code or compiled code, most static analysis tools build a program model of the source code or compiled code of the program. The tool can then identify the code problems it is designed to detect by extracting context-specific information (e.g., patterns, etc.) from the program model. The analysis that can be performed by the tool varies based on the level of detail that the underlying program model provides. The level of detail of the program model has a significant impact on the effectiveness and performance of the static analysis tool as well as the effectiveness and performance of the underlying program model. That is, the more aspects of a program (e.g., features, etc.) that are supported by the program model, the larger and more multifaceted the program model will be. This complexity leads to a decrease in performance but also to an increase in effectiveness. On the other hand, if certain aspects of a program are not going to be tested by the static analysis tool, there is no need to provide built-in support for such aspects in the program model, thereby improving performance. It is desirable to build a program model that is less redundant (improving performance) and also has high effectiveness.

[0009] The term "true positive" or "TP" refers to when a static analysis tool (e.g., an analytical approach) correctly identifies a problem (e.g., a code problem). The term "true negative" or "TN" refers to when a static analysis tool correctly ignores something that is not a problem. The term "false positive" or "FP" refers to when a static analysis tool incorrectly reports a problem (e.g., a code problem). The term "false negative" or "FN" refers to when a static analysis tool incorrectly ignores a problem.

[0010] The term "efficacy" refers to the capabilities of a static analysis tool (e.g., an analysis approach). If a static analysis tool generates a large number of TPs and TNs while minimizing FPs and FNs, the static analysis tool has high effectiveness. Conversely, if a static analysis tool generates a large number of FPs and FNs while keeping the number of TPs and TNs relatively small, the static analysis tool has low effectiveness.

[0011] The term "performance" can refer to execution time (e.g., processing power, etc.), space (e.g., main memory, hard disk, and the like) requirements (e.g., for static analysis tools, building program models, and the like), or both. For example, high performance means low space requirements and fast execution time, while low performance means high space requirements and slow execution time.

[0012] The term "pattern" refers to information that is to be extracted from a program model. For example, a pattern can be formulated as a query, as a code fragment, or a pattern can appear as a comment in the source code. Using SQL databases as an analogy, a SQL query itself can be considered a pattern.

[0013] The term "instance" refers to a concrete subset of a program model that is extracted by the application of a pattern. Using an SQL database as an analogy, one can think of an instance as the result of applying a SQL query.

[0014] The present disclosure relates to a system and method for adaptively generating a program model for static analysis of source code or compiled code of a program to identify code problems in the program (e.g., security vulnerabilities, code smells, coding convention violations, insecure flows that are not guaranteed to be safe, secrets, etc.). Conventional static analysis tools forcefully generate a definite program model based on a common classification of analysis approaches for software testing (e.g., linting-based approaches, intraprocedural analysis-based approaches, interprocedural analysis-based approaches, etc.). In contrast, a static analysis tool according to the present disclosure adaptively or dynamically generates a program model with an appropriate level of granularity (e.g., an appropriate set of supported features or aspects of the program under test, etc.) based on user-defined patterns to be extracted from the program model (e.g., based on the type of tests to be performed on the software program).

[0015] The techniques disclosed herein may determine the type of information required by the user-selected patterns and generate / extract a set of corresponding features (e.g., aspects, etc.) that allow for extraction of instances of the patterns if supported by the tool's underlying program model. The techniques disclosed herein may use predefined relationships between features and program models with such features. In various embodiments, a code scanner (e.g., a static analysis tool, etc.) according to the present disclosure generates a program model that can resolve all user-defined patterns for extraction from the code. By selectively constructing a program model with features based on user-selected patterns in the source code, redundant data pre-computation and analysis by the code scanner is avoided, thereby improving the performance of subsequent analysis steps while maintaining validity, and further adapting the program model well, which is especially important in resource-constrained environments such as continuous integration (CI) or continuous deployment (CD) environments.

[0016] 1 illustrates one embodiment of a networked computing environment 100 suitable for managing code for a software project. In the illustrated embodiment, the networked computing environment 100 includes a source code repository 110, one or more client devices 120, a code scanner 130, and a model lookup data store 140, all connected via a network 150. In other embodiments, the networked computing environment 100 includes different or additional elements. Furthermore, functionality may be distributed among the elements in a manner different than that described. For example, while the source code repository 110 and the model lookup data store 140 are shown as separate entities, in some embodiments the corresponding functionality is provided by the same storage device of a single computing system (e.g., a server, etc.).

[0017] Source code repository 110 includes one or more computer-readable storage media that store code for one or more software projects. In one embodiment, source code repository 110 stores code for an SCM system. An SCM system may store multiple versions of code for a software project to allow for rolling back updates, allowing developers to see the historical status of the code, etc.

[0018] Client devices 120 are computing devices on which software engineers may edit code and commit updates to code repository 110. For example, client devices 120 may be desktop workstations where engineers download portions of code from source code repository 110, make and test revisions in a development environment, and upload the revised code to source code repository 110. Multiple engineers may each use a corresponding client device 120 to revise code and commit those revisions to source code repository 110 at any time. Known suitable techniques may be used to manage conflicts between updates made to code by different engineers at approximately the same time. As will be described in more detail below, engineers may also use client devices 120 to input patterns to be extracted from source code during testing.

[0019] The code scanner 130 continuously or periodically (e.g., hourly, daily, etc.) scans the code in the source code repository 110 to identify code issues (e.g., security vulnerabilities, code smells, coding standard violations, insecure flaws, secrets, etc.). In one embodiment, the code scanner 130 includes one or more static analysis tools (e.g., having one or more program analysis approaches). Each static analysis tool scans the code (or a portion of the code) in the programming language for which the tool is intended to be used to identify code issues of a predefined type. The static analysis tools may generate a report with information about the identified code issues. Each static analysis tool may generate a report that includes all code issues identified after scanning the code (or a specified portion of the code). Alternatively, the static analysis tool may generate a separate report for each identified code issue (e.g., immediately after identifying the code issue). Static analysis tools are generally evaluated based on metrics including TP, TN, FP, FN, effectiveness, and performance.

[0020] As input, the code scanner 130 takes from the source code repository 110 the source code of the program, and from the client device 120 a set of predefined patterns to be extracted from the source code during testing. The code scanner 130 further takes as input model lookup data from the model lookup data store 140 to generate a dynamic program model having a required level of granularity according to a set of identified features extracted from the set of predefined patterns input by a user (e.g., by input via the client device 120). The model lookup data store 140 includes one or more computer-readable storage media that store predefined (model lookup) data (e.g., lookup tables, etc.) indicating relationships between features (e.g., aspects, etc.) and program models having such features or providing support for such features (e.g., the program models shown in FIG. 2, etc.). Details of the configuration and operation of the code scanner 130 are provided below in conjunction with FIGS. 3 and 4.

[0021] Network 150 provides a communication channel through which other elements in networked computing environment 100 communicate. Network 150 may include any combination of local and wide area networks using wired or wireless communication systems. In one embodiment, network 150 uses standard communication technologies and protocols. For example, network 150 may include communication links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), 3G, 4G, 5G, code division multiple access (CDMA), digital subscriber line (DSL), etc. Examples of networking protocols used to communicate over network 150 include multiprotocol label switching (MPLS), transmission control protocol / Internet protocol (TCP / IP), hypertext transfer protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP). Data exchanged over network 150 may be represented using any suitable format, such as HyperText Markup Language (HTML) or Extensible Markup Language (XML). In some embodiments, some or all of the communications links of network 150 may be encrypted using any suitable technology or technique.

[0022] FIG. 2 is a block diagram illustrating an example program model, program model dependencies, and a general program analysis approach associated with the program model. As described above, a static analysis tool builds a program model of source code or compiled code before analyzing it. The tool then extracts patterns from the model and evaluates the patterns to identify code problems. The analysis approach (e.g., types of tests, etc.) of a static analysis tool varies based on the level of detail provided by the underlying constructed program model. Also, the program model used by a static analysis tool has a significant impact on its effectiveness and performance.

[0023] There are many different standard program models used by static analysis tools as well as compilers. Most of them are based on graphs that model various aspects of a program in terms of nodes and edges. Figure 2 shows examples of different program models that may be used by static analysis tools. The models shown in Figure 2 are illustrative of program models and are not intended to be a (limiting) comprehensive list of program models. Those skilled in the art will understand that the set of program models used in accordance with the present disclosure can be adapted for program models not shown in Figure 2.

[0024] The program models 210 to 280 in FIG. 2 are described in detail below. Furthermore, as shown in FIG. 2, the various program models (represented as boxes 210 to 280) are layered. 2 But another program model M 1 is a dependency of or is another program model M 1 If contained by M 2 The box is M 1 is embedded in the box.

[0025] Parse Tree (or Abstract Syntax Tree (AST)) 210 is a hierarchical presentation of the source code created by the parser. Control-Flow Graph (CFG) 220 is a graph that represents the (procedural) control flow of a program. CFG 220 depends on Parse Tree 210. Data Dependence Graph (DD) 230 is a graph that represents the (procedural) data flow in a program. For example, if a statement / expression calculates a value and stores it in a variable x, and this variable is used in another expression y, then there is a data dependency between x and y. DD 230 depends on CFG 220.

[0026] A Call Graph (CG) 240 is a graph that represents the call hierarchy in a program. The CG 240 depends on the CFG 220. An Interprocedural Control-Flow Graph (ICFG) 250 is an interprocedural control-flow graph. The ICFG 250 depends on the CG 240. A Control Dependence Graph (CDG) 260 is a control dependency graph that models control dependencies. For example, if a statement s1 controls the execution of another statement s2, then s2 is control-dependent on s1. The CDG 260 depends on the CFG 220. A Program Dependence Graph (PDG) 270 is a combination of a data dependency graph and a control dependency graph. The PDG 270 depends on the DD 230 and the CDG 260. A System Dependence Graph (SDG) 280 includes PDGs 270 that are connected by interprocedural edges. SDG 280 depends on PDG 270 and ICFG 250. As is evident from Figure 2, program models 220-280 transitively depend on parse tree 210, which can be considered a relatively superficial program representation. SDG 280 is the most accurate model that transitively depends on and therefore encompasses all other program models 210-270.

[0027] In general, static analysis approaches (e.g., various static analysis tools) can be broadly divided into three categories: linting-based analysis approaches, intraprocedural analysis approaches, and interprocedural analysis approaches. Among the three approaches, linting-based analysis approaches are relatively low in complexity (less advanced than the other two approaches), intraprocedural analysis approaches are relatively medium in complexity, and interprocedural analysis approaches are relatively high in complexity (more advanced than the other two approaches).

[0028] Static analysis tools that fall under or apply the linting-based analysis approach typically utilize a program model that is very superficial and geared towards detecting patterns at the lexical or parse tree level. Linting-based analysis approaches are typically lightweight and therefore perform very well. Of the exemplary program models shown in FIG. 2, the parse tree model 210 would be a suitable program model for this type of analysis. Static analysis tools that fall under or apply the intraprocedural analysis approach utilize a program model that allows analysis to be performed within the context of a function, and therefore are unable to capture data and control flow across function boundaries. Of the exemplary program models shown in FIG. 2, the model contained in PDG 270 would be a suitable program model for this type of analysis. Static analysis tools that fall under or apply the interprocedural analysis approach utilize a program model that allows analysis across function boundaries. Compared to other techniques, interprocedural analysis is a relatively comprehensive analysis technique (among the three approaches described above) since it considers more aspects of the program. Of the exemplary program models shown in FIG. 2, ICFG250, CG240, and SDG280 would be suitable models for this type of analysis.

[0029] As described above in relation to FIG. 2, the three analysis approaches (or corresponding static analysis tools) require different program models with different levels of granularity. In general, the more advanced the analysis, the higher the requirements regarding the granularity of the underlying program model. While the linting-based approach may operate on the parse tree 210, the intraprocedural approach requires a program model with a level of granularity ranging between the parse tree 210 and the PDG 270, and the interprocedural approach requires a model with a level of granularity ranging between the PDG 270 and the SDG 280, which can be considered the most advanced program model of the models shown in FIG. 2, i.e., the program model that represents most of the features of the original program. However, the level of complexity in the analysis approach (or corresponding static analysis tool) and program model impacts both performance and effectiveness.

[0030] In general, the more advanced an approach or static analysis tool is, and the more complex the underlying program model, the higher its effectiveness and the lower its performance. Thus, linting-based approaches have a relatively low potential effectiveness and a relatively high potential performance. As a shallow analysis technique, linting-based approaches are well suited to large programs because the analysis as well as the model are simplified (i.e., relatively high performance). A drawback is that linting-based approaches model only a small number of aspects / features of a program, leading to a relatively low effectiveness. At the other end of the spectrum, interprocedural analysis approaches have a low potential effectiveness and a low potential performance. Interprocedural analysis approaches utilize a very rich program model that encompasses a large number of aspects / features of a program. Due to the rich (high level of detail) program model, this analysis technique requires more resources (i.e., relatively low performance) and therefore scales less well to large code bases compared to linting-based techniques. However, due to the richness of the program model, interprocedural analysis has relatively high effectiveness because FN and FP are less likely to occur. Intraprocedural analysis lies in the middle of the range, with moderate effectiveness and performance.

[0031] Moreover, performance constraints impose limitations on the contexts in which these different approaches are applied. For example, linting-based approaches work well in integrated development environments (IDEs) and CI / CD environments because they are fast and provide rapid feedback. Intraprocedural approaches also serve as local tools to help developers find code problems (e.g., security vulnerabilities) in their code. On the other hand, interprocedural approaches are not optimal for CI / CD environments due to performance limitations of developers that may reduce developer speed and productivity in CI / CD settings. Hence, interprocedural analysis is often provided as a dedicated service running on a server farm or as a dedicated tool that should be executed locally by developers on high-end development machines. In summary, traditionally, each analysis approach or corresponding static analysis tool (e.g., linting-based analysis approach or tool, intraprocedural analysis approach or tool, interprocedural analysis approach or tool, etc.) is designed and built for a specific application context and relies on a fixed program model.

[0032] Forcing the use of a specific program model removes the versatility of which environments these analysis tools can be used in. This is especially true in performance-constrained environments such as CI / CD. For example, interprocedural approaches that provide a relatively high level of effectiveness are hardly applicable due to the performance constraints of CI / CD environments. Furthermore, forcing a specific program model may lead to features or aspects being incorporated into the program model that are not necessarily tested or used by the tool, thereby reducing performance.

[0033] To overcome the above problems, the present disclosure describes a system and method for dynamically constructing a program model with an appropriate level of granularity based on user-defined (anti-)patterns to be extracted from the program model. Not pre-computing and analyzing redundant data can improve the performance of subsequent analysis steps while maintaining effectiveness. The adaptive static analysis and dynamic program model generation by the code scanner 130 removes the traditional distinction between traditional linting, intraprocedural analysis approaches, and interprocedural analysis approaches (and corresponding forced generation of program models) by automatically adapting the granularity of the dynamic program model to its use case (e.g., based on user-entered pattern data, based on the type of tests to be performed on the code, etc.). That is, the code scanner 130 dynamically adjusts the granularity of the dynamic program model to be constructed based on the level of detail / granularity required by the patterns to be extracted from the model, which makes the analysis approach well suited to CI / CD environments since the program model becomes less redundant (improving performance) without sacrificing effectiveness. The adaptive program model approach of the present disclosure thus provides a practical trade-off between effectiveness and performance.

[0034] Details of the adaptive program model generation approach of the code scanner 130 are provided below in connection with Figures 3 and 4. Figure 3 is a data flow diagram 300 and a block diagram of the code scanner 130 shown in Figure 1 according to one embodiment. As shown in Figure 3, the code scanner 130 implementing the adaptive model generation approach includes a pattern analyzer 320, a model builder 350, and a pattern evaluation module 360. The pattern analyzer 320 includes a parser module 322 and a feature extraction module 326, and the model builder 350 includes a model configuration module 352 and a compiler module 356. In other embodiments, the code scanner 130 includes different or additional elements. Furthermore, functionality may be distributed among the elements in a manner different from that described. For example, although the pattern analyzer 320 and the model builder 350 are shown as separate elements, in some embodiments the corresponding functionality is provided by a single computing system (e.g., a server, etc.). The data flow diagram 300 in Figure 3 also illustrates the data flow into the code scanner 130 and between the components of the code scanner 130. As shown in Figure 3, the code scanner 130 takes as input source code 310, patterns 315, and model lookup data 351. The source code 310 may be code of programs (or designated portions of code) that are to be tested for code issues (e.g., security vulnerabilities, code smells, coding convention violations, unsafe flaws, secrets, and the like) by (adaptively) building program models of those programs and running analysis on the program models.

[0035] Patterns 315 include a set of predefined patterns (e.g., specified by a user using client device 120 in FIG. 1) to be extracted from a program corresponding to source code 310 during subsequent analysis and testing. Patterns 315 input to code scanner 130 may be pre-filtered to remove those that are not needed or are inappropriate for the context. For example, patterns that require interprocedural analysis may be filtered out if interprocedural analysis is not available. Model lookup data 351 may be data received from model lookup data store 140, including predefined data (e.g., lookup tables, etc.) indicating relationships between features and program models that have such features or provide support for such features (e.g., program models shown in FIG. 2).

[0036] Examples of various program patterns 315 (and corresponding relationships between patterns, features, and program models) that can be selected by a user for input to the code scanner 130 are provided below by way of instance. In the following examples, the program patterns 315 are grouped by corresponding features with a distinction provided between the features. Although some exemplary patterns, corresponding exemplary features, and corresponding exemplary program models are described below, the adaptive model generation technique according to the present disclosure is not limited to such patterns, features, and models. Those skilled in the art will understand that the adaptive model generation technique of the present disclosure can be applied to other patterns, features, and models as well.

[0037] During testing, the information required by a pattern requires certain features to be built into the program model itself so that the pattern can be properly solved / answered / executed in the first place. In the example program patterns below, the corresponding features and the corresponding program models required to be able to extract the pattern are also identified for each program pattern.

[0038] Parse Tree / AST Hierarchy Features: Parse tree pattern extraction is one of the simplest forms of static analysis since it relies on the parse tree as the basis of the program model and can be generated by the parser without further computation. Information that can be extracted from the parse tree includes variable / class / struct / interface names and hierarchy information.

[0039] The following snippet (Pattern Example 1) is a code instance from a Ruby on Rails application with the pattern highlighted in bold:

[0040]

number

[0041] It is.

[0042] Pattern Example 1 can be found by traversal of the parse tree. That is, to extract a pattern such as Pattern Example 1 from a program, the underlying program model needs to have the characteristics of a parse tree / AST hierarchy. The parse tree model 210 in FIG. 2 is sufficient to satisfy / extract the pattern shown in Pattern Example 1.

[0043] Static Type Information Features / Dynamic Type Information Features: Type information is useful for extracting patterns based on the (return) types of variables, methods, and functions. The complexity of computing types varies based on programming languages. In general, it can be said that the difference in complexity lies between statically typed and dynamically typed programming languages. More specifically, considering that statically typed languages ​​provide type information explicitly in the source code, type inference for statically typed languages ​​requires less cost / involvement compared to dynamically typed languages.

[0044] The following example pattern (Example Pattern 2) shows a snippet written in the programming language Go, which is a statically typed language. Example Pattern 2 searches for all functions that return an error type. Since Go requires function returns to be explicitly typed, the parse tree is sufficient to extract the type from the signature.

[0045]

number

[0046] It is.

[0047] A pattern such as the above pattern example 2 can be detected by traversing the parse tree. That is, to be able to extract a pattern such as pattern example 2, the underlying program model needs to have the characteristics of static type information. The parse tree model 210 in FIG. 2 is sufficient to extract this pattern.

[0048] Below is a similar example pattern (Pattern Example 3) in the dynamically typed programming language Ruby, which searches for all instances of function foo in the source code that return a literal string. Pattern Example 3 returns two different values / types based on the argument values ​​passed in.

[0049]

number

[0050] It is.

[0051] For dynamically typed languages, types are not explicitly stated in the source code. Hence, types cannot be inferred directly from the source code. Instead, we need to perform an analysis on the PDG (as a lower bound) to extract all return values ​​from the function definition to determine in which cases a literal string is returned. That is, to extract a pattern such as Example Pattern 3, the underlying program model needs to have dynamic type information characteristics. The PDG model 270 in Figure 2 is sufficient to extract this pattern.

[0052] For cases where you have varying return values ​​and return types that can only be determined by the function's arguments or the calling context, even PDG is not a sufficient program model, so you need to use SDG, which allows you to infer types across function boundaries and analyze the context in which the function is called.

[0053] Intraprocedural and Interprocedural Control Flow Features: The following snippet (Pattern Example 4) expresses a partial secret-leaking pattern. To be able to infer what the secret-leaking conditions are for, the program model needs to provide intraprocedural control flow information that orders all statements and expressions based on their execution order and highlights the path conditions that lead to a call to fmt.Println that leaks a variable labeled as secret.

[0054]

number

[0055] It is.

[0056] To be able to extract a pattern like pattern example 4, the underlying program model needs to have intra-procedural control flow characteristics. The CFG model 220 in Figure 2 is sufficient to extract this pattern.

[0057] The following snippet (Pattern Example 5) illustrates the case where we need a program model that is based on interprocedural analysis (including caller / callee relationships), where we are looking for a function foo that returns an unchecked error type at the caller. This is another example where the complexity of the analysis and the model required is determined by the programming language being analyzed and is based on the language type (i.e., dynamic vs. static). For the programming language Go, being a static language with a preference for static dispatch, it is sufficient to build an ICFG model that extracts patterns like the following pattern (Pattern Example 5):

[0058]

number

[0059] It is.

[0060] That is, the underlying program model needs to have inter-procedural control flow characteristics to be able to extract a pattern such as pattern example 5. The ICFG model 250 in Figure 2 is sufficient to extract this pattern.

[0061] Intra-procedural and Inter-procedural Data Flow: Below is an example code snippet (Pattern Example 6) where parameters passed to a function can flow into a database execution statement that can lead to a SQL injection attack. In the below example, there is a data flow from the parameter input to the db.Execute sink, i.e., Pattern Example 6

[0062]

number

[0063] It is.

[0064] That is, the program model needs to have the characteristics of intra-procedural data flow in order to be able to extract a pattern such as pattern example 6. The DD model 230 in Fig. 2 is sufficient to extract this pattern.

[0065] The following example (Pattern Example 7) is more complex because there is data flow between different functions that requires interprocedural data flow analysis. Below is an example of an interprocedural data flow pattern where we want to check if user input (provided by Source() function) flows into a sensitive sink, Sink().

[0066]

number

[0067] It is.

[0068] To be able to extract a pattern like the example pattern 7, the program model needs to provide interprocedural control flow features and interprocedural data flow features. The SDG model 280 in Figure 2 is a suitable model to detect the illustrated data flow.

[0069] As described above, the linkages between features extracted from a pattern and program models having such features (e.g., the linkages between features and models for pattern examples 1-7 above) may be stored as model lookup data 351 in model lookup data store 140. In one embodiment, model lookup data 351 may be a lookup table that allows code scanner 130 to search for each feature identified / extracted for an input pattern to find the best program model having such feature (e.g., high-performance program model, optimized program model, etc.). An example of model lookup data 351 stored in model lookup data store 140 (e.g., storing the relationship between the models shown in FIG. 2 and the features corresponding to pattern examples 1-7 above) is shown below as Table 1.

[0070] [Table 1]

[0071] In Table 1, rows represent different program models and columns represent different features. That is, in Table 1, rows represent feature requirements, i.e., different program models required to properly satisfy a given feature. In Table 1, a cell is set to 1 if the feature (column) transitively requires the corresponding program model (row), otherwise the cell is set to 0. It should be noted that the list of features and program models listed in Table 1 is illustrative and not restrictive or comprehensive. The purpose of Table 1 is to clearly show one embodiment of model lookup data for any set of features and models. Those skilled in the art will understand that additional or alternative features and additional or alternative program models for satisfying the features can be added to the columns and rows of Table 1, respectively. Examples of features not listed in Table 1 may include more specific programming language-based characteristics, such as differentiation between static and dynamic languages ​​(e.g., as mentioned in connection with pattern examples 3 and 5 above).

[0072] Returning to FIG. 3 , the pattern analyzer 320 performs a pre-analysis on the patterns 315 to identify which features should be incorporated (e.g., built-in) into the dynamic program model. Based on the pre-analysis, the pattern analyzer 320 generates feature configuration data 328 (e.g., a set of features extracted from the patterns 315). More specifically, the patterns 315 are input to a parser module 322 of the pattern analyzer 320. The parser module 322 can parse each of the input patterns 315 and generate a pattern parse tree 324, i.e., a hierarchical representation of each pattern 315. That is, the pattern parse tree 324 is a structural / hierarchical representation of the source code corresponding to each pattern 315. For example, if the patterns 315 are to be formulated in the form of an SQL query, the parse tree 324 will provide a parse tree representation of the SQL query. In one embodiment, the adaptive program model generation methodology is independent of any particular programming language, so any parser capable of creating a parse tree from source code can be used. The parse tree 324 generated from the input pattern 315 by the parser module 322 is input to a feature extraction module 326, which evaluates and analyzes the pattern parse tree 324 to identify / extract corresponding features (e.g., aspects of the program being tested).

[0073] Additionally, feature extraction module 326 aggregates the identified or extracted features corresponding to patterns 315 into a set of features as feature configuration data 328 and outputs feature configuration data 328 to model builder 350. More specifically, feature extraction module 326 traverses pattern parse tree 324 to determine the type of information required by each pattern 315. Based on this determination, feature extraction module 326 generates feature configuration data 328 (e.g., a set of features). Thus, if feature extraction module 326 determines that one or more of pattern definitions 315 require "Parse Tree / AST Hierarchy" features, this information is included in feature configuration data 328.

[0074] The feature configuration data 328 may be the union of all unique features extracted from the input pattern 315 (e.g., a query),

[0075]

number

[0076] For example, if one pattern 315 extracts information related to the "Parse Tree / AST Hierarchy" feature while another pattern 315 extracts information requiring the "Intraprocedural Control Flow" feature, then both of these features can be written as:

[0077]

number

[0078] The characteristic configuration is recorded as follows.

[0079] In some embodiments, information linking a particular pattern (such as pattern 315) to a particular feature may be predetermined and stored as feature lookup data (e.g., a lookup table, etc.). The feature lookup data may thus indicate relationships between patterns 315 and corresponding features (e.g., aspects, etc.) that should be supported by the program model to be able to extract each pattern 315. The feature extraction module 326 may then utilize the feature lookup data to identify features corresponding to each pattern 315 and generate feature configuration data 328.

[0080] The model builder 350 uses the feature configuration data 328 to generate a dynamic program model 358 with a required level of granularity depending on the set of features included in the feature configuration data 328. The resulting program model 358 can be used for different purposes. In the embodiment shown in FIG. 3, the program model 358 is used to identify code problems (e.g., unsafe flaws, secrets, coding convention violations, etc.) in the source code 310 by inputting patterns 315 to a pattern evaluation module 360, generating instances 370 of the input patterns 315, and analyzing the instances 370 for problems. As shown in FIG. 3, the model builder 350 includes a model configuration module 352 and a compiler module 356. The model configuration module 352 receives the feature configuration data 328 (e.g., a set of features, etc.) as input and receives model lookup data 351 from the model lookup data store 140.

[0081] Based on the set of features included in the feature configuration data 328, the model configuration module 352 may perform a lookup operation to search for corresponding program models from the model lookup data 351 (e.g., Table 1 above) to dynamically select all program models required to satisfy the set of features in the feature configuration data 328.

[0082] The above exemplary model lookup data 351 and exemplary feature configurations shown in Table 1

[0083]

number

[0084] Continuing, because the feature “Intraprocedural Control Flow” requires a CFG model, which in turn relies on a Parse Tree / AST model, a model lookup operation by model configuration module 352 may yield corresponding data from model lookup data 351. For example, the columns in Table 1 may be represented as bit vectors, such that model configuration module 352 may extract the bit vector 11000000 for the “Intraprocedural Control Flow” feature (i.e., the data corresponding to the “Intraprocedural Control Flow” feature column in Table 1).

[0085] To determine (e.g., build, generate, etc.) a dynamic program model that satisfies all queries / patterns 315 input to the code scanner 130, the model builder 350 may store all features f in the feature configuration F as feature configuration data 328. x , and aggregates all identified models in the model configuration M as model configuration data 354. In one embodiment, the model configuration module 352 iterates over the features f x The bit vector m corresponding to x To search for and generate model configuration data 354, the formula

[0086]

number

[0087] We use bit vectors to implement this consolidation by applying 0 =00000000 means "bitwise OR" starting with 00000000. In other words, the model configuration module 352 identifies, summarizes, and integrates the program models required in the model configuration M as model configuration data 354, where the model configuration M includes all the program models to properly resolve all the features required to extract all the patterns / queries input as patterns 315.

[0088] Continuing with the above example, feature f1 = Parse Tree / AST hierarchical features are model configuration m 1 = 10000000, and the feature f 2 = Intraprocedural control flow is modeled as m 2 = 11000000. The model configuration module 352 calculates the model configuration M of the model configuration data 354 as follows:

[0089]

number

[0090] It is.

[0091] The compiler module 356 takes the calculated model configuration data 354 (e.g., M=11000000 above) and the source code 310 as input. The compiler module 356 then uses the input model configuration data 354 to determine which dynamic program model 358 should be generated from the source code 310 so that it can properly satisfy the pattern / query input in the pattern 315. For example, the model configuration M=11000000 requires the Parse Tree / AST model and the CFG model to be activated. To this end, with the model configuration data 354 in the program and the source code 310 as input, the compiler module 356 invokes the parser, which is responsible for constructing the program model as configured by the input model configuration data 354 (e.g., if the model configuration M=11000000, construct the Parse Tree / AST model and the CFG model), and then combines the constructed model into the dynamic program model 358.

[0092] During subsequent analysis of the source code, the code scanner 130 may activate the pattern evaluation module 360 ​​to extract patterns 315 from the dynamic program model 358 input to the pattern evaluation module 360 ​​and generate instances 370 of the patterns 315 to identify and report code problems.

[0093] Figure 4 is a flow chart illustrating a method 400 for adaptively generating a program model, according to one embodiment. The steps in Figure 4 are illustrated in terms of the code scanner 130 performing the method 400. However, some or all of the steps (blocks) may be performed by other entities or components. Additionally, some embodiments may perform steps in parallel, perform steps in a different order, omit one or more of the steps, or perform alternative or different steps.

[0094] 4, method 400 begins at block 410, where code scanner 130 receives source code 310 for a software project (e.g., by retrieving source code from source code repository 110). At block 420, code scanner 130 receives data corresponding to a set of predefined patterns that have been selected by a user (e.g., by selecting patterns from source code 310 on one or more client devices 120) or automatically selected by a static analysis tool based on the type of testing to be performed. At block 430, parser module 322 of code scanner 130 parses each of the patterns received at block 420 to generate a pattern parse tree.

[0095] In block 440, the feature extraction module 326 of the code scanner 130 evaluates and parses the pattern parse tree to identify / extract features that correspond to the set of patterns received in block 420. In block 440, the feature extraction module 326 parses the identified or extracted features that correspond to the patterns into a set of features (e.g.,

[0096]

number

[0097] In block 450, the model construction module 352 of the code scanner 130 receives model lookup data that connects features extracted from the patterns (e.g., by searching Table 1, discussed above as model lookup data 351, from the model lookup data store 140) with program models having such features.

[0098] In block 460, the model configuration module 352 of the code scanner 130 uses the model lookup data received in block 450 to perform a lookup operation to search for a respective program model for each identified feature included in the feature set of the feature configuration data generated in block 440, thereby locating all program models (e.g., feature configurations) required to satisfy the pattern input in block 420.

[0099]

number

[0100] The model configuration module 352 in block 460 also generates model configuration data by iterating through each feature included in the feature set and combining the program models identified for the extracted features. The method 400 then proceeds to block 470, where the compiler module 356 of the code scanner 130 generates a dynamic program model from the source code received in block 410 based on the model configuration data generated in block 460 (e.g., model configuration M=11000000, etc.) so that all patterns received in block 420 can be properly satisfied. The method 400 may then proceed to subsequent analysis and reporting steps to test the source code received in block 410 for code issues. For example, in block 480, the pattern evaluation module 360 ​​of the code scanner 130 may extract the pattern (received in block 420) from the dynamic program model (generated in block 470), generate instances of the pattern, and identify code problems in the program based on the instances.

[0101] 5 is a block diagram illustrating an example computer 500 suitable for use as one or more client devices 120, or a code scanner 130, or for hosting a source code repository 110, or a model lookup data store 140, or for implementing functionality corresponding to method 400. The example computer 500 includes at least one processor 502 coupled to a chipset 504. The chipset 504 includes a memory controller hub 520 and an input / output (I / O) controller hub 522. A memory 506 and a graphics adapter 512 are coupled to the memory controller hub 520, and a display 518 is coupled to the graphics adapter 512. A storage device 508, a keyboard 510, a pointing device 514, and a network adapter 516 are coupled to the I / O controller hub 522. Other embodiments of the computer 500 have various architectures.

[0102] 5, storage device 508 is a non-transitory computer-readable storage medium, such as a hard drive, a compact disc read-only memory (CD-ROM), a DVD, or a solid-state memory device. Memory 506 holds instructions and data used by processor 502. Pointing device 514 may be a mouse, a trackball, a touch screen, or other type of pointing device and may be used in combination with keyboard 510 (which may be an on-screen keyboard) to input data into computer system 500. Graphics adapter 512 displays images and other information on display 518. Network adapter 516 couples computer system 500 to one or more computer networks, such as network 150.

[0103] The types of computers used by the entities in Figures 1 and 3 may vary depending on the embodiment and the processing power required by the entities. For example, a system hosting source code repository 110 may include multiple blade servers working together to provide the described functionality, while client device 120 may be a desktop workstation or a tablet. Additionally, computer 500 may lack some of the components described above, such as keyboard 510, graphics adapter 512, and display 518.

[0104] Some portions of the above description describe embodiments in terms of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the computing arts to effectively convey the substance of their work to others skilled in the art. These operations, while described functionally, computationally, or logically, will be understood to be implemented by computer programs, including instructions for execution by a processor or equivalent electrical circuitry, microcode, or the like. Moreover, without loss of generality, it has also proven convenient at times to refer to these arrangements of functional operations as modules.

[0105] As used herein, a reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearance of the phrase "in one embodiment" in various places in this specification does not necessarily all refer to the same embodiment. Similarly, the use of "a" or "an" before an element or component is done merely for convenience. This description should be understood to mean that there are one or more elements or components, unless it is clear that something else is meant.

[0106] When values ​​are described as "approximate" or "substantially" (or derivatives thereof), such values ​​are to be construed to be accurate to ±10%, unless another meaning is clear from the context. For example, "approximately ten" should be understood to mean "in the range from 9 to 11."

[0107] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements and may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, "or" means an inclusive "or" and not an exclusive "or." For example, condition A or condition B is satisfied by either: A is true (or exists) and B is false (or does not exist); A is false (or does not exist) and B is true (or exists); and both A and B are true (or exist).

[0108] Upon reading and comprehending this disclosure, one skilled in the art will still appreciate further alternative structural and functional designs for systems and processes for adaptively generating program models by performing pre-analysis on user-defined patterns. Thus, although specific embodiments and applications have been illustrated and described, it should be understood that the described subject matter is not limited to the precise structures and components disclosed. The scope of protection should be limited only by any claims issued.

Claims

1. 1. A system for adaptively generating a program model, comprising: one or more processors; a memory operatively coupled to the one or more processors, the memory being configured to, when executed by the one or more processors, cause the one or more processors to: receiving the source code of the program to be tested for the code problem; receiving a set of predefined patterns to be tested in the source code; generating feature configuration data by determining a set of features corresponding to the received set of predefined patterns; identifying a set of program models by selecting, for each feature in the set of features, one or more program models from among a plurality of program models that are required to evaluate the feature; constructing a dynamic program model based on the set of identified program models, the dynamic program model adapted to resolve each of the patterns included in the received set of predefined patterns; testing the source code for code problems by extracting an instance of each of the set of predefined patterns from the dynamic program model; a memory including instructions for causing the A system comprising:

2. The system of claim 1 , wherein the dynamic program model is an optimized program model that has no support for features other than those included in the set of features.

3. The instructions that, when executed by the one or more processors, cause the one or more processors to receive the set of predefined patterns, cause the one or more processors to: receiving data corresponding to the set of predefined patterns from one or more client devices based on one or more user actions; or automatically generating data corresponding to the set of predefined patterns based on a user interaction on a client device to select an analysis approach; The system of claim 1 , further comprising instructions to:

4. The instructions that, when executed by the one or more processors, cause the one or more processors to generate the feature configuration data may cause the one or more processors to: parsing each of the patterns in the received set of predefined patterns to generate a pattern parse tree; parsing the pattern parse tree to extract the set of features; The system of claim 1 , further comprising instructions to:

5. The instructions that, when executed by the one or more processors, cause the one or more processors to generate the feature configuration data may cause the one or more processors to: receiving feature lookup data indicating predefined relationships between a plurality of features and respective example patterns that can be resolved by the plurality of features; performing, for each pattern in the received set of predefined patterns, a feature lookup operation to identify a corresponding feature from the received feature lookup data; determining the set of features based on the feature lookup operation performed for each pattern in the received set of predefined patterns; The system of claim 1 , further comprising instructions to:

6. The instructions that, when executed by the one or more processors, cause the one or more processors to identify the set of program models, cause the one or more processors to: receiving model lookup data indicating predefined relationships between a plurality of features and respective program models optimized to satisfy the plurality of features; for each feature in the set of features, performing a model lookup operation using the received model lookup data to identify a corresponding program model optimized to satisfy the feature; identifying the set of program models based on the model lookup operation performed for each feature in the set of features; The system of claim 1 , further comprising instructions to:

7. The instructions that, when executed by the one or more processors, cause the one or more processors to identify the set of program models, cause the one or more processors to: extracting a bit vector for each feature in the set of features from the received model lookup data, each bit vector indicating the optimized program model for that feature; generating a combined bit vector by combining the plurality of bit vectors by performing a bitwise OR operation, the combined bit vector representing the dynamic program model; The system of claim 6 further comprising instructions to:

8. 8. The system of claim 7, wherein the model lookup data is a lookup table that stores relationships between a plurality of features and a plurality of program models, and the lookup table indicates, for each of the plurality of features, an optimal program model from among the plurality of program models that has support for the feature.

9. 1. A method for adaptively generating a program model, comprising: receiving source code for a program to be tested for a code problem; receiving a set of predefined patterns to be tested in the source code; generating feature configuration data by determining a set of features corresponding to the received set of predefined patterns; identifying a set of program models by selecting, for each feature in the set of features, a program model from among a plurality of program models that is optimized for the feature; building a dynamic program model based on the set of identified program models, the dynamic program model adapted to resolve each of the patterns included in the received set of predefined patterns; testing the source code for code problems by extracting an instance of each of the set of predefined patterns from the dynamic program model; A method comprising:

10. 10. The method of claim 9, wherein the dynamic program model is an optimized program model that has no support for features other than those included in the set of features.

11. The step of receiving a set of predefined patterns comprises: receiving data corresponding to the set of predefined patterns from one or more client devices based on one or more user actions; or automatically generating data corresponding to the set of predefined patterns based on a user interaction on the client device to select an analysis approach. The method of claim 9, comprising any one of

12. The step of generating the feature configuration data includes: parsing each of the patterns in the received set of predefined patterns to generate a pattern parse tree; parsing the pattern parse tree to extract the set of features; 10. The method of claim 9, comprising:

13. The step of generating the feature configuration data includes: receiving feature lookup data indicating predefined relationships between a plurality of features and respective example patterns that can be resolved by said plurality of features; performing, for each pattern in the received set of predefined patterns, a feature lookup operation to identify a corresponding feature from the received feature lookup data; determining the set of features based on a feature lookup operation performed for each pattern in the received set of predefined patterns; 10. The method of claim 9, comprising:

14. The step of identifying a set of program models comprises: receiving model lookup data indicating predefined relationships between a plurality of features and respective program models optimized to satisfy the plurality of features; for each feature in the set of features, performing a model lookup operation using the received model lookup data to identify a corresponding program model optimized to satisfy the feature; identifying a set of program models based on the model lookup operation performed for each feature in the set of features; 10. The method of claim 9, comprising:

15. The step of identifying a set of program models comprises: extracting a bit vector for each feature in the set of features from the received model lookup data, each bit vector indicating an optimized program model for that feature; generating a combined bit vector by combining a plurality of bit vectors by performing a bitwise OR operation, the combined bit vector being indicative of the dynamic program model; The method of claim 14 further comprising:

16. 16. The method of claim 15, wherein the model lookup data is a lookup table that stores relationships between a plurality of features and a plurality of program models, and the lookup table indicates, for each of the plurality of features, an optimal program model from among the plurality of program models that has support for the feature.

17. A non-transitory computer readable medium having stored thereon a computer executable program that, when executed, causes a computing system to: receiving the source code of the program to be tested for the code problem; receiving a set of predefined patterns to be tested in the source code; generating feature configuration data by determining a set of features corresponding to the received set of predefined patterns; identifying a set of program models by selecting, for each feature in the set of features, a program model from among a plurality of program models that is optimized for the feature; constructing a dynamic program model based on the set of identified program models, the dynamic program model adapted to resolve each of the patterns included in the received set of predefined patterns; testing the source code for code problems by extracting an instance of each of the set of predefined patterns from the dynamic program model; A non-transitory computer-readable medium comprising instructions to cause

18. 20. The non-transitory computer-readable medium of claim 17, wherein the dynamic program model is an optimized program model that has no support for features other than those included in the set of features that define the feature configuration data.

19. The instructions, when executed, cause the computing system to identify the set of program models, the instructions causing the computing system to: receiving model lookup data indicating predefined relationships between a plurality of features and respective program models optimized to satisfy the plurality of features; for each feature in the set of features, performing a model lookup operation using the received model lookup data to identify a corresponding program model optimized to satisfy the feature; identifying the set of program models based on a model lookup operation performed for each feature in the set of features; 20. The non-transitory computer readable medium of claim 17 comprising instructions to cause:

20. The instructions, when executed, cause the computing system to identify the set of program models, the instructions causing the computing system to: extracting from the received model lookup data a bit vector for each feature in the set of features defining the feature configuration data, each bit vector indicating an optimized program model for that feature; generating a combined bit vector by combining a plurality of bit vectors by performing a bitwise OR operation, the combined bit vector representing the dynamic program model; 20. The non-transitory computer readable medium of claim 19 comprising instructions to cause:

21. 21. The non-transitory computer-readable medium of claim 20, wherein the model lookup data is a lookup table that stores relationships between a plurality of features and a plurality of program models, the lookup table indicating, for each of the plurality of features, an optimal program model from among the plurality of program models that has support for the feature.

Images