Patent Description:
Configuration as Code (CaC) is a process for managing application configuration data in configuration code. An example of CaC is Infrastructure as Code (laC), which is used (e.g., by cloud computing centers) to implement, in a type of configuration code referred to as "infrastructure code," the infrastructure on which various applications may be run.

Per typical CaC convention, configuration code for configuring an application is defined separately from the application code that determines the functionality of the application. Thus, for example, application code may define an operation in which a message is broadcast over a particular data bus, while configuration code may define the properties of the data bus.

Typically, the application code of a cloud software system (i.e., a software system configured to run on cloud-computing infrastructure) is distributed over loosely coupled "services," also referred to as "microservices," with each service implementing different respective functions within the context of the application. For example, an online sales application may include (i) a façade service, which receives orders via an externally-facing application program interface (API), (ii) an order service, which manages the orders, (iii) a stock service, which tracks the stock available for sale, and (iv) a payment service, which manages payments for the orders. The services generally communicate with each other over a layer of infrastructure known as a "service mesh," which may be configured in infrastructure code.

<CIT> describes a system and method for detecting software misconfigurations, performance problems, security issues, and the like at a remote machine, in particular, detecting software misconfiguration at a remote machine by a control server. <CIT> describes a flaw classifier model that classifies a computing system as one which contains or does not contain one or more flaws that affect a performance of the computing system. <CIT> describes a method and a security platform for performing security assessment and vulnerability testing of software applications based at least in part on application metadata in order to determine an appropriate assurance level and associated test plan that includes multiple types of analysis.

In accordance with an aspect of the present invention, there is provided a system as set out in the first of the appending independent claims. In accordance with another aspect of the present invention, there is provided a method as set out in the second of the appending independent claims. In accordance with a further aspect of the present invention, there is provided a computer software product as set out in the third of the appending independent claims. Features of various embodiments are set out in the appending dependent claims.

There is also disclosed herein examples of a system that includes an output device and a processor. The processor is configured to analyze a software system, which includes an application subsystem and a configuration subsystem, so as to generate an output describing (i) one or more operations performed by the application subsystem, and (ii) one or more configurations for the application subsystem, which are provided by the configuration subsystem. The processor is further configured to identify, based on the output, at least one flaw in the software system that results from a combination of the operations with the configurations, and to output, via the output device, an indication of the flaw in response to identifying the flaw.

In some examples, the output includes a first data structure describing the operations and a second data structure describing the configurations, and the processor is configured to identify the flaw by querying the first data structure and the second data structure.

In some examples, the first data structure includes a data-flow graph (DFG).

In some examples, the first data structure includes a document object model (DOM).

In some examples, the first data structure includes a control-flow graph (CFG).

In some examples, the second data structure includes a JavaScript Object Notation (JSON) structure.

In some examples, the second data structure includes an Extensible Markup Language (XML) structure.

In some examples, the processor is configured to identify the flaw based on a manner in which the configurations configure a resource used by one of the operations.

In some examples, the processor is configured to identify the flaw in response to the configurations configuring the resource as accessible from an Internet.

In some examples, the operation exchanges data with the resource, and the processor is configured to identify the flaw in response to the configurations permitting access to the resource by users who are unauthorized to access the data.

In some examples, the resource includes a log, the operation writes data to the log, and the processor is configured to identify the flaw in response to the configurations not configuring the log to be stored persistently.

In some examples, the resource includes an application programming interface (API).

In some examples, the processor is configured to identify the flaw by:.

In some examples, the application subsystem includes software code that defines the operations, and the processor is configured to analyze the software system by parsing the software code.

In some examples, the application subsystem includes software code that defines the operations, and the processor is configured to analyze the software system by running the code.

In some examples, the processor is further configured to modify code of the configuration subsystem so as to correct the flaw.

In some examples, the at least one flaw includes multiple flaws, the processor is further configured to compute an order of priority for correcting the flaws, and the processor is configured to output the indication so as to indicate the order of priority.

In some examples, the processor is configured to compute the order of priority based on different respective levels of security vulnerability associated with the positions.

In some examples, the processor is configured to compute the order of priority such that correcting a first flaw affecting one of the services that exchanges data with a greater number of others of the services is prioritized over correcting a second flaw affecting another one of the services that exchanges data with a lesser number of others of the services.

In some examples, the flaws include multiple security vulnerabilities associated with different respective resources, and the processor is configured to compute the order of priority such that correcting any one of the security vulnerabilities associated with one of the resources that is configured, by the configurations, as accessible from an Internet is prioritized over correcting any other one of the security vulnerabilities associated with another one of the resources that is not configured, by the configurations, as accessible from the Internet.

In some examples, the flaw results from one of the operations being non-idempotent and being allowed, by the configurations, to be executed multiple times without deduplication.

In some examples, the flaw results from the configurations allowing a particular one of the operations to be performed without a prior authentication of a user of the application subsystem.

In some examples, the flaw results from the configurations configuring a service in the application subsystem to have a position in a topology of the application subsystem that renders the service susceptible to a particular type of attack associated with a particular one of the operations performed by the service.

In some examples, the flaw results from one of the operations being vulnerable to a particular type of attack for which the configurations do not provide a protection mechanism.

In some examples, the flaw results from one of the operations sending unencrypted data without the configurations providing a mechanism for securing the unencrypted data.

In some examples, the flaw results from (i) a first service in the application subsystem transferring data to an address that is assigned, by the configurations, to a second service in the application subsystem, and (ii) the second service writing to a location to which access by users who are unauthorized to access the data is permitted.

In some examples, the flaw results from (i) a first service in the application subsystem transferring a query or a command to an address that is assigned, by the configurations, to a second service in the application subsystem, and (ii) the second service not providing a defense against an injection attack.

In some examples, the flaw includes a security vulnerability resulting from the configurations configuring a first service in the application subsystem and a second service in the application subsystem to use a common resource.

In some examples, the flaw results from the configurations exposing a resource not used by the application subsystem.

In some examples, the flaw results from one of the operations conflicting with one of the configurations.

In some examples, the application subsystem includes software code that defines the operations, and the configurations configure a process for building the software code.

In some examples, the configurations configure a process for testing the application subsystem.

In some examples, the configurations configure a deployment of the application subsystem.

In some examples, the configurations configure runtime behavior of the application subsystem.

In some examples, the configuration subsystem includes a software infrastructure on which the operations are performed.

There is also disclosed herein examples of a method that includes using a processor, analyzing a software system, which includes an application subsystem and a configuration subsystem, so as to generate an output describing (i) one or more operations performed by the application subsystem, and (ii) one or more configurations for the application subsystem, which are provided by the configuration subsystem. The method further includes, based on the output, identifying at least one flaw in the software system that results from a combination of the operations with the configurations, and in response to identifying the flaw, outputting an indication of the flaw.

There is also disclosed herein examples of a computer software product that includes a tangible non-transitory computer-readable medium in which program instructions are stored. The instructions, when read by a processor, cause the processor to analyze a software system, which includes an application subsystem and a configuration subsystem, so as to generate an output describing (i) one or more operations performed by the application subsystem, and (ii) one or more configurations for the application subsystem, which are provided by the configuration subsystem. The instructions further cause the processor to identify, based on the output, at least one flaw in the software system that results from a combination of the operations with the configurations, and to output an indication of the flaw in response to identifying the flaw.

In the context of the present application, including the claims, the term "application code" may refer to any computer code, written in any compiled or scripting language, that performs any suitable operations within the context of a computer application. Such operations may include, for example, performing queries, exchanging data, and processing data. In addition to code for performing operations, application code may include associated configurations. For example, application code written in Java may include "application. property" configurations, which may include, for example, database connection strings. Application code may include both proprietary code, developed by the proprietor of the application, and third-party code.

In the context of the present application, including the claims, the term "configuration code" may include any computer code, written in any compiled or scripting language, that configures a computer application in any way, such as by configuring the building, testing, provisioning, or deployment of the application, by assigning values to environment variables, by configuring resources used by the application, or by configuring the runtime environment of the application. In a cloud software system, configuration code may include declarations and functions associated with a cloud operating system (OS), an API Gateway, a Domain Name System (DNS), a service mesh, firewalls and other network components, and/or cloud orchestration. Configuration code may be used by a CaC tool such as Kubernetes, Docker, Istio, Ansible, Terraform by HashiCorp, Inc. , AWS, Azure, Google Cloud, or Jenkins.

In the context of the present application, including the claims, the term "application subsystem" refers to the portions of a software system whose properties are associated with or derive from application code. Thus, for example, an application subsystem may include application code, optionally together with binary files compiled from the application code. Similarly, the term "configuration subsystem" refers to the portions of a software system whose properties are associated with or derive from configuration code. Thus, for example, a configuration subsystem may include configuration code, optionally together with binary files compiled from the configuration code (e.g., a Docker image compiled from Docker configuration code). The execution of the software system, in which both application code and configuration code are run, may be said to belong both to the application subsystem and to the configuration subsystem of the software system.

In the context of the present application, including the claims, the "topology" of an application sub-system refers to the scheme per which the services belonging to the application sub-system exchange data (or "communicate") with each other and with external entities. The "position" of any service in the topology refers to the functioning of the service in the context of this scheme, such that ascertaining the position of the service is equivalent to ascertaining which other services exchange data with the service, and whether the service also exchanges data with any external entities. A topology may be represented as a graph in which each node represents a different respective service, and each edge connecting any of the nodes to another node or to a point outside the graph represents the exchanging of data.

In the context of the present application, including the claims, a "flaw" in a software system may include any defect that compromises the security of the system (i.e., increases the vulnerability of the system to attack) or compromises the performance of the system. A flaw may be corrected by removing code, adding code, or modifying code.

It is challenging, when performing software-system testing, to generate output that includes an accurate and precise list of flaws in the software system. For example, including every line of code that is potentially problematic, such as every line of code in which sensitive data is communicated or stored, leads to an imprecise list containing many false positives. Moreover, even if such an approach is employed, more subtle flaws may be missed.

Advantageously, however, the present inventors realized that this challenge may be overcome, at least for software systems utilizing CaC. In particular, the present inventors realized that by analyzing both the application subsystem and the configuration subsystem of such software systems and correlating between the analyses, flaws may be identified more accurately and precisely. For example, the communication of sensitive data may not be identified as cause for a flaw, provided that the configuration subsystem configures an encryption mechanism for the data. Conversely, a configuration of a firewall with permissive policies may be identified as cause for a flaw, in the event that the permissive policies are not required by the application subsystem.

Hence, embodiments of the present invention provide a processor configured to analyze both subsystems, so as to identify both the operations of the application subsystem and the configurations of the configuration subsystem. Subsequently to identifying the operations and configurations, the processor looks for any flaw that results from a combination of the operations with the configurations. The processor further outputs an indication of each such flaw, and, optionally, automatically corrects the flaw, e.g., by adding, removing, or modifying a configuration.

In some embodiments, in the event that multiple flaws are found, the processor further computes an order of priority for correcting the flaws. For example, the processor, based on the operations and configurations, may ascertain the topology of the application subsystem, and then compute the order of priority based on the topology. Thus, for example, the processor may prioritize correcting a flaw in a service that exchanges data with a larger number of other services over correcting a similar type of flaw in another service that exchanges data with a smaller number of other services. Alternatively or additionally, in the event that the flaws include multiple security vulnerabilities associated with different respective resources, the processor may prioritize a security vulnerability associated with a publicly-accessible resource over another security vulnerability associated with a non-publicly-accessible resource, given that the former vulnerability is more likely to be exploited.

In some cases, the processor identifies a problematic operation/configuration combination beginning with the application subsystem. For example, the processor may first identify an operation of the application subsystem that calls an application programming interface (API) with a particular argument. The processor may then ascertain whether the argument is declared in the configurations, and provided the argument is declared, the manner in which the argument is declared. In response thereto, the processor may ascertain that the combination of the API call with the declaration, or lack of declaration, is cause for a flaw. For example, the processor may ascertain that an operation stores sensitive data to a container or file, but the configurations configure the container as publicly accessible or fail to encrypt the file.

In other cases, the processor identifies a problematic combination beginning with the configuration subsystem. For example, the processor may first identify a declaration in the configurations. The processor may then ascertain whether any of the operations calls an API with an argument declared by the declaration, and provided that an operation calls the API, the manner in which operation calls the API. In response thereto, the processor may ascertain that the combination of the declaration with the API call, or lack of API call, is cause for a flaw. For example, the processor may ascertain that a resource is declared in the configurations, thus exposing the resource to users of the system, but no operation uses the resource.

Reference is initially made to <FIG>, which is a schematic illustration of a system <NUM> for analyzing a software system, in accordance with some embodiments of the present invention.

System <NUM> comprises a computer <NUM>, such as a desktop or laptop computer. Computer <NUM> comprises a processor <NUM>, configured to analyze a software system <NUM> including an application subsystem <NUM>, which performs various operations defined in application code <NUM>, and a configuration subsystem <NUM>, which configures application subsystem <NUM> per configurations defined in configuration code <NUM>.

Typically, computer <NUM> further comprises a network interface <NUM>, such as a network interface controller (NIC). Using network interface <NUM>, processor <NUM> may obtain, via a network <NUM> (e.g., the Internet), application code <NUM> and/or configuration code <NUM>. Alternatively or additionally, the processor may obtain, via network <NUM>, binary files compiled from application code <NUM> and/or configuration code <NUM>, and/or a trace of the execution <NUM> of software system <NUM>. (<FIG> depicts execution <NUM> spanning application subsystem <NUM> and configuration subsystem <NUM>, given that execution <NUM> includes the execution of the application code in the context of the configuration code.

For example, the application and configuration code may be stored, by the proprietor of the software system, remotely from computer <NUM>, e.g., in a local area network (LAN) <NUM> of the proprietor. In such an instance, processor <NUM> may obtain the code from one or more computers <NUM> belonging to the proprietor. (It is noted that the code may be split among multiple storage drives in LAN <NUM>, such as among the hard drives of different respective computers <NUM> belonging to the LAN.

Based on the aforementioned code, binary files, and/or execution trace, processor <NUM> analyzes software system <NUM> so as to identify any flaws in the software system that result from a combination of the operations of the application subsystem with the configurations of the configuration subsystem. Typically, system <NUM> further comprises a display <NUM>, and processor <NUM> is configured to display, on display <NUM>, output from the analysis. Alternatively or additionally, the processor, using network interface <NUM>, may communicate the output, via network <NUM>, to a computer <NUM>, and computer <NUM> may then display the output on another display <NUM>.

In other embodiments, the processor of one of computers <NUM>, rather than processor <NUM>, performs the software-system analysis described herein. In such embodiments, the application code and configuration code may be stored locally on the analyzing computer, or the analyzing computer may obtain at least some of the code from another computer <NUM>, using a suitable network interface. Output from the analysis may then be displayed on display <NUM>.

In some cases, the configuration subsystem includes (i.e., the configuration code defines) a software infrastructure implemented on computers <NUM> and/or on one or more servers <NUM> belonging to a cloud-computing network <NUM>, and the operations of the application subsystem are performed on the software infrastructure. In such cases, application code <NUM> may include multiple application (APP) modules <NUM> defining the operations performed by different respective services on the software infrastructure, each application module <NUM> being configured by a different respective configuration (CONFIG) module <NUM>. Processor <NUM> may obtain code, binary files, and/or a trace of execution <NUM> from servers <NUM>, for analysis of the software system.

In general, the configurations defined in configuration code <NUM> may configure the application subsystem in any suitable way. For example, the configurations may configure a process for testing the functionality of the application subsystem. (Such configurations may be defined using an open-source tool such as Jenkins, for example. ) Alternatively or additionally, the configurations may configure (or "provision") a resource, such as a firewall or gateway, used by the application subsystem. Alternatively or additionally, the configurations may configure the deployment of the application subsystem. (Such configurations may be defined using an laC tool such as Terraform by HashiCorp, Inc. , for example. ) Alternatively or additionally, the configurations may configure the runtime behavior of the application subsystem, e.g., by configuring load balancing between servers <NUM> on which the operations of the application subsystem are performed.

In general, processor <NUM> may be embodied as a single processor, or as a cooperatively networked or clustered set of processors. In some embodiments, the functionality of processor <NUM>, as described herein, is implemented solely in hardware, e.g., using one or more Application-Specific Integrated Circuits (ASICs) or Field-Programmable Gate Arrays (FPGAs). In other embodiments, the functionality of processor <NUM> is implemented at least partly in software. For example, in some embodiments, processor <NUM> is embodied as a programmed digital computing device comprising a central processing unit (CPU). Program code, including software programs, and/or data are loaded for execution and processing by the CPU. The program code and/or data may be downloaded to the processor in electronic form, over a network, for example. Alternatively or additionally, the program code and/or data may be provided and/or stored on non-transitory tangible media, such as magnetic, optical, or electronic memory. Such program code and/or data, when provided to the processor, produce a machine or special-purpose computer, configured to perform the tasks described herein.

For an example of software that may be executed by processor <NUM> (or by a processor of a computer <NUM>) to perform the functionality described herein, reference is now additionally made to <FIG>, which shows an example module diagram for such software, in accordance with some embodiments of the present invention.

Processor <NUM> is configured to analyze software system <NUM> so as to generate an output describing (i) one or more operations performed by the application subsystem, and (ii) one or more configurations for the application subsystem, which are provided by the configuration subsystem. (It is noted that this output is typically not exposed to any users of system <NUM>. ) Typically, each of the subsystems is analyzed by a different respective software module executed by the processor; in particular, an application-subsystem analyzer 24a analyzes the application subsystem, while a configuration-subsystem analyzer 24b analyzes the configuration subsystem. The output of the analysis thus includes two components: a first component <NUM>, which describes the operations and is output by application-subsystem analyzer 24a, and a second component <NUM>, which describes the configurations and is output by configuration-subsystem analyzer 24b.

In some embodiments, application-subsystem analyzer 24a analyzes the application subsystem by parsing application code <NUM>. In response to parsing the application code, the application-subsystem analyzer may build a data-flow graph (DFG) describing the operations of the application subsystem, e.g., as described in <CIT>. (Each node of the DFG corresponds to a statement that uses a variable, such as an assignment of a value to the variable or the use of the variable in a function call, and the edges of the DFG represent the dependencies between these statements. ) Alternatively or additionally, the application-subsystem analyzer may build a document object model (DOM) describing the operations, e.g., as described in <CIT>. First component <NUM> may thus include a DFG, a DOM, and/or any other suitable data structure that describes the operations, such as a control-flow graph (CFG) or call graph (CG).

Alternatively or additionally, the application-subsystem analyzer may analyze binary files compiled from the application code, and generate first component <NUM>, which may comprise any suitable data structure, in response thereto.

Similarly, configuration-subsystem analyzer 24b may analyze the configuration subsystem by parsing the configuration code. In response to parsing the configuration code, the configuration-subsystem analyzer may build a JavaScript Object Notation (JSON) structure, an Extensible Markup Language (XML) structure, and/or any other suitable data structure describing the configurations, such as a data structure convertible to JSON. Second component <NUM> may thus include any of these data structures. Alternatively or additionally, the configuration-subsystem analyzer may analyze binary files compiled from the configuration code, and generate second component <NUM>, which may comprise any suitable data structure, in response thereto.

Alternatively or additionally, the application-subsystem analyzer or the configuration-subsystem analyzer may run application code <NUM>, in the context of the configurations, using any suitable execution tracer, e.g., as described in <CIT> Subsequently, the application-subsystem analyzer may generate first component <NUM>, and the configuration-subsystem analyzer may generate second component <NUM>, by querying the resulting trace of execution <NUM>.

In other embodiments, the processor executes a single analysis module, which generates a single-component output describing both the operations and the configurations. Such an output may include, for example, an execution trace generated by running the application code as described above.

Typically, the software executed by processor <NUM> further includes a flaw identifier 24c, which is configured to identify, based on the output from the analysis module(s), any flaw that results from a combination of the operations with the configurations. In other words, flaw identifier 24c correlates between the operations and configurations so as to identify any flaws. Typically, flaw identifier 24c performs this identification by querying the data structures that describe the operations and configurations. A list of predefined queries for identifying operations and configurations of various types, along with rules for interpreting the results of the queries so as to identify any flaws, are specified in flaw-identifying logic <NUM>. The queries may be executed in any suitable query language, such as any query language described in <CIT> or <CIT>.

Typically, the software executed by processor <NUM> further includes a flaw handler 24d. In response to flaw identifier 24c identifying at least one flaw, flaw handler 24d may output an indication of the flaw. For example, the flaw handler may display (e.g., on display <NUM>) a warning indicating the flaw, the warning optionally including references to particular portions of application code <NUM> and/or configuration code <NUM> that are cause for the flaw.

Alternatively or additionally to outputting an indication of the flaw, the flaw handler may automatically modify configuration code <NUM> so as to correct the flaw. For example, the flaw handler may add a configuration to, remove a configuration from, or modify an existing configuration in configuration code <NUM>. As specific examples, the flaw handler may add new authorization requirements to an API, remove the declaration of a port or another resource that is not used by the application subsystem, change the declaration of a resource so as to limit access thereto, or add a whitelist or blacklist of users to the configuration code.

Alternatively to automatically correcting a flaw, the flaw handler may output a proposed correction to the flaw, such as any of the example corrections described above.

It is emphasized that the module diagram in <FIG> is provided by way of example only, and that processor <NUM> may perform the functionality described herein using any suitable set of software and/or hardware modules.

Reference is now made to <FIG>, which is a flow diagram for an example algorithm <NUM> for identifying flaws in software system <NUM> (<FIG>), in accordance with some embodiments of the present invention. Algorithm <NUM> is executed by the processor subsequently to generating data structures describing the operations and configurations. Typically, most of the steps of algorithm <NUM> are performed by flaw identifier 24c (<FIG>), with the last one or two steps being performed by flaw handler 24d.

Per algorithm <NUM>, the processor queries the data structure describing the operations so as to identify any of the operations performed by the application subsystem that are potentially cause for a flaw. For example, the processor may query the operations data structure for API calls in which the operations interface with external services or resources in a potentially security-compromising manner. An example of such an API call is a call to the API "SaveData" with the arguments "credit_card_num" and "MY_FILE," per which the operation saves sensitive data assigned to the local variable credit_card_num to the file assigned to the environment variable MY_FILE. (The processor may ascertain that sensitive data is assigned to credit_card_num by applying a machine-learned classifier, which is trained to identify names of variables to which sensitive data are likely assigned, to the string "credit_card_num.

For each of the identified operations, the processor queries the data structure describing the configurations so as to check whether the configurations allow the flaw to be realized. For example, for each potentially security-compromising API call, the processor may query the configurations data structure for the definition of the API and/or for the declaration of at least one of the arguments to the API call. (If the API call is in an application module <NUM> (<FIG>), the processor typically queries the portion of the configurations data structure that describes the configuration module <NUM> corresponding to the application module. ) For example, continuing the example above, the processor may query the configurations data structure for a declaration of the environment variable MY_FILE.

Subsequently, based on the result of the second query, the processor ascertains whether the combination of the operation with the configurations is cause for a flaw. For example, continuing the example above, the processor may ascertain whether MY_FILE is declared as an encrypted file. If MY_FILE is declared without encryption, the processor may identify the combination of the API call with the declaration of MY_FILE as cause for a flaw. (Many other examples of problematic combinations are provided below, e.g., in the Additional Examples subsection of the present description.

More specifically, at an operations-querying step <NUM>, the processor queries the operations data structure for a specific type of operation (e.g., communication or saving of sensitive data), as specified by flaw-identifying logic <NUM> (<FIG>). Based on the results of the query, the processor ascertains, at a first query-result-assessing step <NUM>, whether the type of operation is performed. If yes, the processor, at a corresponding-configuration-querying step <NUM>, queries the configurations data structure for a corresponding configuration, i.e., a configuration whose presence or absence may allow the flaw potentially caused by the operation to be realized. The corresponding configuration is also specified by flaw-identifying logic <NUM>.

Next, based on flaw-identifying logic <NUM>, the processor ascertains, at a combination-assessing step <NUM>, whether the combination of the operation with the presence or absence of the configuration is problematic, i.e., cause for a flaw. If the combination is cause for a flaw, the processor adds the flaw to a list of flaws, at a list-augmenting step <NUM>. For example, the processor may add the line of application code in which the operation is defined along with the line of configuration code containing the corresponding configuration. Optionally, the processor may further add a description of the flaw (e.g., "sensitive data stored to unencrypted file"). The processor may further add a suggested correction for the flaw (e.g., by adding an existing file declaration modified so as to encrypt the file).

Subsequently to performing list-augmenting step <NUM>, the processor checks, at a checking step <NUM>, whether any more queries for operation types are specified by flaw-identifying logic <NUM>. Similarly, the processor performs checking step <NUM> if the queried-for operation type is not performed, or if the combination of the operation with the configurations does not allow a flaw to be realized. If at least one more query for operation types remains, the processor returns to operations-querying step <NUM>.

Subsequently to ascertaining, at checking step <NUM>, that no queries for operation types remain, the processor checks, at a list-checking step <NUM>, whether the list contains any flaws. If yes, the processor, at a list-outputting step <NUM>, outputs the list so as to indicate the flaws. The output may be performed via any suitable output device, such as display <NUM> or display <NUM> (<FIG>), network interface <NUM> (<FIG>), and/or an audio speaker.

In alternate embodiments, the analysis of the configuration subsystem is performed during the execution of algorithm <NUM>, rather than prior to the execution of algorithm <NUM>. For example, in response to identifying an API call with an argument at first query-result-assessing step <NUM>, the processor may analyze the configuration subsystem (e.g., by parsing the configuration code) so as to find the declaration of the argument.

Some problematic combinations - for example, the exposure, by the configurations, of a resource that is unused by the operations - are best identified by first querying the configurations data structure, and only subsequently querying the operations data structure. Hence, the processor may use other algorithms, alternatively or additionally to algorithm <NUM>, to identify such combinations.

In this regard, reference is now made to <FIG>, which is a flow diagram for another example algorithm <NUM> for identifying flaws in software system <NUM>, in accordance with some embodiments of the present invention. Per algorithm <NUM>, the processor identifies any of the configurations that are potentially cause for a flaw. For each of the identified configurations, the processor checks whether the operations allow the flaw to be realized. Typically, most of the steps of algorithm <NUM> are performed by flaw identifier 24c (<FIG>), with the last one or two steps being performed by flaw handler 24d.

More specifically, at a configurations-querying step <NUM>, the processor queries the configurations data structure for a specific type of configuration (e.g., the declaration of a specific type of resource), as specified by flaw-identifying logic <NUM>. As a purely illustrative example, the processor may find any ports exposed by the configurations by executing the query open_port:=Find_in_Config("Deployment. containerPort"), which queries the configurations data structure for any port numbers declared in a Kubernetes path "Deployment.

Based on the results of the query, the processor ascertains, at a second query-result-assessing step <NUM>, whether the type of configuration exists. If yes, the processor, at a corresponding-operation-querying step <NUM>, queries the operations data structure for a corresponding operation, i.e., an operation whose performance or lack thereof may allow the flaw potentially caused by the configuration to be realized. The corresponding operation is also specified by flaw-identifying logic <NUM>. Continuing the example above, after ascertaining that the query result "open_port" is not null, the processor may find any port numbers used by the operations by executing the query used_ports:=Find_in_App("ServerSocket. New"), which queries the operations data structure for any port number used in the instantiation of a Java ServerSocket object.

Next, the processor performs combination-assessing step <NUM>, as described above with reference to <FIG>. If the combination is cause for a flaw, the processor performs list-augmenting step <NUM>, as described above with reference to <FIG>. Continuing the example above, the processor may identify a flaw if at least one result in "open_port" is not included in "used_port.

Subsequently, the processor checks, at checking step <NUM>, whether any more queries for configuration types are specified by flaw-identifying logic <NUM>. Similarly, the processor performs checking step <NUM> if the queried-for configuration type does not exist, or if no problematic combination with the configuration type exists. If at least one more query for configuration types remains, the processor returns to configurations-querying step <NUM>.

Subsequently to ascertaining, at checking step <NUM>, that no queries for configuration types remain, the processor performs list-checking step <NUM> and, optionally, list-outputting step <NUM>, as described above with reference to <FIG>.

In alternate embodiments, the analysis of the application subsystem is performed during the execution of algorithm <NUM>, rather than prior to the execution of algorithm <NUM>. For example, in response to identifying, at second query-result-assessing step <NUM>, a configuration that includes a declaration, the processor may analyze the application subsystem (e.g., by querying a DFG) so as to ascertain whether the operations include an API call with an argument declared by the declaration.

Notwithstanding <FIG>, it is noted that, in some cases, a problematic combination (i.e., a combination that is cause for a flaw) may include multiple operations and/or multiple configurations. In such cases, identifying the combination may comprise querying the operations data structure multiple times and/or querying the configurations data structure multiple times.

For example, the processor may first identify an operation that includes the API call "HttpPost(MY_URL). " The processor may then identify, in the configurations, a declaration of MY_URL in which MY_URL is assigned the address of a particular service and port (e.g., "http://ServiceB:<NUM>"). The processor may then return to the operations, and identify another API call "HttpPost(Url)," where Url is assigned the value "http://ServiceB:" + MY_PORT. The processor may then return to the configurations, and identify a declaration of MY_PORT in which MY_PORT is assigned the value "<NUM>. " The processor may therefore identify the combination of the two aforementioned API calls with the two aforementioned declarations as cause for a flaw, given that this combination causes two Hypertext Transfer Protocol (HTTP) POST operations to post to the same service and port.

The following are additional examples of flaws in software system <NUM> (<FIG>) resulting from a combination of the operations of the application subsystem with the configurations of the configuration subsystem. Each of the example flaws below may be identified using any of the techniques described above with reference to <FIG>, and/or any other suitable techniques.

One common type of flaw results from the manner in which the configurations configure an API or any other resource used by one of the operations. Examples of this type include the following:.

Other example flaws include the following:.

Table <NUM> below lists examples (i)-(xviii) described above, summarizing, for each example, the properties of the operations and configurations that, in combination, cause a flaw in the software system.

Reference is now made to <FIG>, which is a schematic illustration of an example execution <NUM> of software system <NUM> (<FIG>), in accordance with some embodiments of the present invention.

In the example shown in <FIG>, software system <NUM>, when executed, implements a cloud-based sales application on cloud-computing network <NUM> (<FIG>). In this application, a façade service <NUM> receives queries, orders, and payment information from users via network <NUM>. Façade service <NUM> sends the queries to a stock service <NUM>, which, in response to each received query, queries a stock database (DB) <NUM> and returns the result of the query to the façade service. The façade service sends the orders to an order service <NUM>, which enters each received order into an order database <NUM>. (Order service <NUM> may further query order database <NUM> and return the results of the queries to the façade service. ) The façade service sends the payment information to a payment service <NUM>, which enters the information into a payment database <NUM>.

<FIG> further shows a data storage <NUM>, which is used by stock service <NUM> but is also directly accessible via the Internet. Order service <NUM> is also directly accessible via the Internet, and order database <NUM> is directly accessible to the façade service.

As described above with reference to <FIG>, the functionality of each service may be defined in a different respective application module <NUM>, and may be configured in a different respective configuration module <NUM>. Typically, the configurations further include a configuration of the service mesh, which handles communication between the services.

In this scenario, processor <NUM> (<FIG>) may identify various flaws resulting from a combination of the operations of the application subsystem with the configurations of the configuration subsystem.

In some embodiments, in the event that the processor identifies multiple flaws in the software system, the processor (e.g., flaw handler 24d (<FIG>)) computes an order of priority for correcting the flaws. Subsequently, the processor outputs the indication of the flaws so as to indicate the order of priority. For example, the processor may list the flaws in the order of priority, typically with the flaw having the highest priority for correction listed first. Alternatively or additionally, the processor may define a numerical or alphabetical scale for the priorities (e.g., a scale of <NUM>-<NUM> or {"high priority," "medium priority," and "low priority"}), and output, together with the indication of each flaw, the number or alphabetical string, from the scale, that corresponds to the priority computed for the flaw.

In general, the processor may base the order of priority on any suitable factors.

For example, if the flaws include multiple security vulnerabilities associated with different respective resources, the processor may compute the order of priority such that correcting any one of the security vulnerabilities associated with one of the resources that is configured, by the configurations, as accessible from the Internet is prioritized over correcting any other one of the security vulnerabilities associated with another one of the resources that is not configured, by the configurations, as accessible from the Internet. Thus, for example, the processor may prioritize correcting a security vulnerability associated with a public message bus over correcting another security vulnerability associated with a private message bus.

Alternatively or additionally, the processor may first ascertain, based on the operations and configurations, different respective positions, in the topology of the application subsystem, of the services in the application subsystem. This may be done by identifying operations in which services exchange data, along with configurations in which the API arguments used for the data exchanges are defined.

For example, with reference to <FIG>, the processor may ascertain that façade service <NUM> is a front-end service, based on (a) a call, by the façade service, to a data-exchanging API with an argument "MY_URL," and (b) a configuration in which the environment variable "MY_URL" is assigned an external URL (i.e., a URL including a domain external to the software system). The processor may further ascertain that payment service <NUM> is a back-end service that communicates with façade service <NUM>, based on (a) a call, by the payment service, to a data-exchanging API with an argument "SERVICE1," (b) a configuration in which the environment variable "SERVICE1" is assigned the address of the façade service, and (c) the lack of any exchange of data by the payment service with an external website.

Subsequently, the processor may compute the order of priority based on the positions.

For example, the processor may compute the order of priority based on different respective levels of security vulnerability associated with the positions. Thus, for example, given a particular type of flaw (e.g., leakage of sensitive data) identified in both the façade service and the payment service, the processor may compute a higher priority for correcting the flaw in the façade service, given that a front-end service is, in general, more vulnerable to an attack capitalizing on the flaw.

Alternatively or additionally, the processor may compute the order of priority such that correcting a first flaw affecting one of the services that exchanges data with a greater number of others of the services is prioritized over correcting a second flaw affecting another one of the services that exchanges data with a lesser number of others of the services. For example, the processor may prioritize correcting a flaw that renders the façade service vulnerable to a denial-of-service (DoS) attack over correcting a similar type of flaw affecting the payment service. Since the façade service exchanges data with three other services, while the payment service exchanges data with only one other service, a DoS attack on the façade service is likely to affect the software system more, relative to a DoS attack on the payment service.

Claim 1:
A system (<NUM>) comprising:
an output device (<NUM>, <NUM>, <NUM>); and
a processor (<NUM>), configured to:
analyze a software system (<NUM>), which includes an application subsystem (<NUM>) comprising application code and a configuration subsystem (<NUM>) comprising Infrastructure as Code, which defines a software infrastructure on which the application code is to run, so as to generate an output (<NUM>, <NUM>) describing:
one or more operations performed by the application subsystem, and
one or more configurations provided for the application subsystem by the software infrastructure;
the processor is further configured to
based on the output, identify at least one flaw in the software system that results from a combination of the operations performed by the application code with the configurations provided by the software infrastructure; and
in response to identifying the flaw, output, via the output device, an indication of the flaw;
wherein the processor analyzes the software system by performing an operation selected from the group of operations consisting of: parsing software code of the software system, analyzing binary files compiled from the software code, and tracing execution of the software code, wherein the operation is performed over both the application code and the software infrastructure.