Automated runtime execution hardening through static system application programming interface (API) data mapping.

Abstract

This invention provides a system and method for implementing automatic runtime execution hardening for software programs under development. In various embodiments, the computing system performs automatic coercion profile generation within the software development environment, where the source code of the software program is compiled or converted to create an executable software program. Automatic coercion profile generation includes accessing artifacts related to the software program from a data storage device, statically analyzing artifacts (including machine code) related to the software program without executing the software program, and generating system API usage data based on the analysis. A platform-specific coercion profile for secure mode hardening functionality is created based on the system API usage data and platform configuration data. When applied to a software program, the platform-specific coercion profile defines actions (including system calls) that the software program is permitted to execute, while blocking other actions (including other system calls).

Description

Technical Field

[0001] Cross - reference to Related Applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 495,220, filed on April 10, 2023, entitled "Automatic Runtime Execution Hardening Through Static System Application Programming Interface (API) Data Mapping", which is hereby incorporated by reference in its entirety.

Background Art

[0002] Background

[0002] As the complexity of software programs has increased and software and computing systems have become targets of attacks and exploitation, the hardening of software programs has become more important. However, current techniques for hardening software programs require manual generation of enforcement profiles, specific technical knowledge regarding enforcement profiles, and platform - specific configurations due to the enforcement profiles being platform - specific. Aspects of the present disclosure relate to this general technical environment. Additionally, while relatively specific problems have been discussed, it should be understood that the examples should not be limited to the solutions to the specific problems identified in the background or elsewhere in the present disclosure.

Summary of the Invention

Means for Solving the Problems

[0003] Summary

[0003] The currently disclosed technology provides a system and method for implementing automated runtime execution hardening, in particular by static system application programming interface ("API") data mapping. In an example, a software development system or a control system of a software development system (collectively, the "Computation System") generates a coercion profile within a software development environment, where the source code of a software program is compiled to create an executable software program, or the source code of a software program is converted into an executable programming language or scripting language without compilation into a machine language program. The coercion profile can function for any call to the operating system, such as from a scripting language, interpreted language, or native language. When generating a coercion profile, the Computation System accesses (e.g., receives or pulls) artifacts related to the software program from a data storage device. The Computation System then analyzes the artifacts related to the software program without executing the software program and generates system API usage data based on the analysis. The Computation System accesses platform configuration data from a data storage device and creates a platform-specific coercion profile for secure mode hardening functionality based on the system API usage data and platform configuration data. The platform-specific enforcement profile is then stored (e.g., pushed) in data storage. When applied to a software program, the platform-specific enforcement profile defines the actions (including system calls) that the software program is allowed to perform, while blocking other actions.

[0004]

[0004] This summary is provided to introduce in a simplified form a set of concepts that will be further described in the following detailed description. This summary is not intended to identify any major or essential features of the claims, nor is it intended to be used to limit the scope of the claims. Additional aspects, features, and / or advantages of the examples are partially described in the following description, partially apparent from this description, or may be known by the practice of this disclosure.

[0005] Brief explanation of the drawing

[0005] Further understanding of the nature and advantages of specific embodiments can be achieved by referring to the remainder of this specification and the drawings, which are incorporated herein by reference and constitute part of this disclosure. [Brief explanation of the drawing]

[0006] [Figure 1]

[0006] An exemplary system for implementing automatic runtime execution hardening for software programs under development and / or deployment is shown. [Figure 2]

[0007] A block diagram illustrating an exemplary data flow for implementing automated runtime execution hardening for software programs under development and / or deployment is shown. [Figure 3]

[0008] A block diagram illustrating an exemplary data flow for implementing automated runtime execution hardening for software programs is shown. [Figure 4A]

[0009] This document provides an exemplary method for implementing automated runtime execution hardening for software programs. [Figure 4B]

[0009] An exemplary method for implementing automatic runtime execution hardening for a software program is shown. [Figure 5]

[0010] A block diagram is shown illustrating the physical components of a computing device in which embodiments of this technology may be implemented. [Modes for carrying out the invention]

[0007] Detailed description of certain embodiments

[0011] Enforcement profiles, such as secure mode profiles, can be used to prevent compromised programs from accessing sensitive information, modifying files, or establishing network connections, thereby protecting the system from potential harm caused by the compromised program. However, generating enforcement profiles can be difficult because it requires a complete understanding of the program's behavior and the system calls it utilizes. Some enforcement profiles, such as seccomp profiles, are platform-dependent; therefore, the configuration for the test or development platform used to generate the enforcement profile must match the configuration for the deployment or end-use system platform protected by the functionality of the enforcement profile. Otherwise, the enforcement profile will be ineffective for its design purpose. It is also important to strike a balance between security and functionality; a profile that is too loose (e.g., too loose or too lenient) will not provide any real hardening (which can indirectly lead to vulnerabilities), while a profile that is too strict may prevent the program from functioning as intended by the program developer.

[0008]

[0012] In typical software development, code changes are stored (e.g., pushed) to a (source) code repository before the build process, and during the build process, the program's source code is compiled (including compilation and linking) to create an executable software program, or the software program's source code is converted into an executable programming language or scripting language without compilation into a machine code program. The build process is dependent on the specific platform configuration. Artifacts generated during the build process are stored in an artifact storage device or artifact repository. As used herein, a repository refers to a location where data is stored and managed, whether it be a (source) code repository, an artifact repository, etc., and in some cases refers to a central location. As used herein, an artifact refers to one of several types of by-products or process-based files or documents generated during the development and / or release of a software program. Artifacts may include executable files, library files, binaries, data files, configuration files, data models, deployment scripts, database definitions, input files, and / or other types of files necessary to run the program. The artifact storage device stores build artifacts, configuration files (including platform configurations), and other data consumed by other components of the system later in the pipeline. After the build process, the program is deployed to one or more different environments or systems, including test systems, pre-production environments, production environments, on-premises environments, cloud environments, and / or managed cloud environments. As used herein, pipeline refers to the process that drives software development through the path of code building, testing, and / or deployment. Pipeline may refer to a continuous integration and continuous deployment ("CI / CD") pipeline, which is a set of processes or steps performed to deliver a new version of the software, or it may refer to at least one of a build pipeline (or software development pipeline) or a release pipeline (or software deployment pipeline).The build pipeline and release pipeline include or provide individual software development environments and software deployment environments.

[0009]

[0013] To harden a program, a common solution involves the developer or user initially establishing or using a test pipeline that includes a test environment. Within the test pipeline, the developer or user manually downloads the program's binary artifacts and uses analysis tools to generate raw system application programming interface ("API") usage data. In some cases, the analysis tools capture the program's interaction with the operating system ("OS"). The raw system API usage data is converted into a platform-specific profile. In some cases, during such conversion, raw system call numbers are converted to names appropriate to the target OS. However, these names may vary depending on the OS version, build version, etc. Also during such conversion, configuration files are created that are supported by the relevant hardening features of the current deployment (e.g., enforcement profiles). The developer or user then manually re-stores (e.g., pushes) the platform-specific profile onto artifact storage. During deployment (within the release pipeline, including the software deployment environment), the platform-specific profile is accessed (e.g., received or pulled) from artifact storage and applied to the program to harden it. The hardened program is then deployed.

[0010]

[0014] However, a common solution requires developers or users to set up dedicated test environments for binary analysis and profiling. Manually generating enforced profiles using external tools requires significant engineering time and effort every time the code is changed, and requires developers or users to have specific technical knowledge of enforced profiling. In some cases, enforced profiles are platform-specific, requiring platform-specific configurations. In other cases, developers or users must write comprehensive test suites, which can result in incomplete profiles that do not cover all cases, as users typically overlook some code flows. Furthermore, every time the code is changed, the test suite must be updated accordingly, the enforced profiles must be regenerated and thoroughly tested, which requires significant engineering work.

[0011]

[0015] This disclosure provides a solution that improves reliability and enables large-scale scalability to a repository without generating significant additional engineering work. In the implementation of this disclosure, automatic forced profiling is implemented within a software development environment, where the source code of a software program (e.g., a software application, software package, or operating system) is compiled to create an executable software program, or the source code of a software program is converted into an executable programming language or scripting language without compilation into a machine language program. After the creation of the executable software program, the system accesses (e.g., receives or pulls) artifacts associated with the executable software program from artifact storage.

[0012]

[0016] This system performs static system call analysis by analyzing the binary of a software program without executing the software program. As used herein, a binary refers to a file containing the machine code of a software program for execution by the computing system. In some cases, the binary, which is an artifact of the software program as described above, is also the compiled or converted output used as input for automatic forced profiling. Other inputs for automatic forced profiling may include other artifacts (e.g., configuration data, data files, input files, model files). As part of this static analysis process, a control flow graph ("CFG") representing the possible execution paths within the software program is created. The CFG is generated by analyzing the binary of the software program and scanning all possible control flow paths starting from all entry points in the main binary and any libraries it uses. The CFG is used to find all calls to system calls in all possible code paths of the software program. Because this analysis considers all possible code paths, a comprehensive list of system calls that the software program might use is obtained. Static system call analysis for automatic forced profiling differs from dynamic system call analysis, which uses recording tools to obtain a list of system calls used during the runtime of the software program being executed. To create such a list, a comprehensive test suite must be constructed that uses every system call. Therefore, dynamic analysis requires a significant amount of manual engineering work and multiple iterations for every code change in order to obtain a comprehensive code coverage test suite.

[0013]

[0017] Based on static analysis, the system outputs system API usage data directly to the next stage in the process. In the example, wrapper functions are used to (a) automatically access (e.g., receive or pull) artifacts from artifact storage, (b) implement analysis tools, and (c) output system API usage data.

[0014]

[0018] The system autonomously accesses platform configuration data or the platform configuration itself (collectively, the "platform configuration") from artifact storage, uses the platform configuration in combination with system API usage data, and creates a platform-specific enforcement profile (e.g., a seccomp profile). The resulting platform-specific enforcement profile is stored (e.g., pushed) on artifact storage for further consumption by the release or deployment pipeline and applied to running executable software programs.

[0015]

[0019] As can be understood from the disclosures herein, this technology provides several technical advantages and solutions to several technical problems. For example, hardening software programs to prevent them from being targeted for attacks and exploits generally presents several technical problems. For example, one technical problem is that current methods for hardening software programs require the manual generation of enforcement profiles. Another technical problem is that developers or users who manually generate enforcement profiles need specific technical knowledge about them. Yet another technical problem is that enforcement profiles are platform-specific, requiring platform-specific configurations, and requiring profile regeneration if the test and deployment environments use different platforms. For large enterprises with vast application portfolios or large or small businesses developing rapidly changing products, manually enabling hardening on a project-by-project basis is not scalable. Yet another technical problem is that manually generated profiles need to be re-verified and re-run every time the code is changed.

[0016]

[0020] This technology provides automatic coercive profile generation within a software development environment, where the source code of a software program is compiled to create an executable software program, or the source code of a software program is converted into an executable programming language or scripting language without compilation into a machine language program. When automatic coercive profile generation is performed, the computing system receives or accesses artifacts related to the software program from a data storage device. Next, the computing system analyzes the artifacts related to the software program without executing the software program and generates system API usage data based on the analysis. The computing system receives or accesses platform configuration data from a data storage device and creates a platform-specific coercive profile for secure mode hardening functionality based on the system API usage data and platform configuration data. The platform-specific coercive profile is then stored on or in a data storage device. When applied to a software program, the platform-specific coercive profile defines the actions (including system calls) that the software program is allowed to perform, while blocking other actions.

[0017]

[0021] In this way, the development and maintenance of a comprehensive test suite to produce enforced profiles is unnecessary. When automated, the enforced profile generation process is less likely to overlook system calls, enabling the creation of enforced profiles in a more efficient and accurate manner. After initial setup, profile generation becomes (fully) automated for all future code changes. Platform information used by the build or development pipeline is utilized for static analysis and profile generation, as these processes are performed within the build or software development environment itself, according to various embodiments. Enforced profiles can also be easily generated for outdated or unmaintained repositories. Furthermore, the examples described herein are easily scalable to numerous entities (e.g., private organizations, corporations, government agencies, etc.) or all of their repositories without requiring significant additional engineering effort. Additionally, in network edge devices, which are less secure dedicated hardware appliances, the automated profile generation process can harden software running on such hardware against AI applications running on it, even if the AI ​​application is compromised.

[0018]

[0022] Various modifications and additions can be made to the embodiments described without departing from the scope of this disclosure. For example, while the embodiments described above refer to specific features, the scope of this disclosure also includes embodiments having different combinations of features and embodiments that do not include all of the features described above.

[0019]

[0023] Next, we move on to the embodiments shown in the drawings. FIGS. 1 to 5 show a method, a system, and a device for implementing software development and / or deployment, particularly a method, a system, and a device for implementing automatic runtime execution hardening of a software program. More specifically, as mentioned above, a method, a system, and a device for implementing automatic runtime execution hardening of a software program by static system API data mapping are shown. The method, the system, and the device shown in FIGS. 1 to 5 refer to examples of different embodiments that include various components and steps, which can be regarded as alternatives in various embodiments or can be used in combination with each other. The description of the illustrated method, system, and device shown in FIGS. 1 to 5 is provided for illustrative purposes and should not be regarded as limiting the scope of various embodiments.

[0020]

[0024] Figure 1 shows an exemplary system 100 for implementing automated runtime execution hardening for software programs under development and / or deployment. System 100 includes a software development system 105 (also called the “build system” or “continuous integration or CI system”) which includes a software development pipeline (also called the “build pipeline”) 110 and a control system 115. In some cases, the software development pipeline 110 and the control system 115 may be integrated as a single system or platform. In other cases, the software development pipeline 110 and the control system 115 are embodied as separate systems. In this example, the software development pipeline 110 provides a software development environment in which software programs are created, while the control system 115 organizes, manages, or controls the software development process and also provides an interface with user devices (user devices 150a to 150n, collectively referred to as "user devices 150"). In some examples, the control system 115 includes a software hardening system 120, which may include a enforced profile generator 125. The software hardening system 120 is used, in some cases, to improve or enhance the security of software programs by utilizing the enforced profile generator 125 to create enforced profiles that protect the systems on which the software programs are executed. Enforced profiles protect these systems by defining the actions (including system calls) that the software programs are allowed to perform, while blocking other actions.

[0021]

[0025] System 100 further includes one or more data storage devices 130, each of which may include at least one of a source code repository 130a, a platform configuration database 130b, an artifact repository 130c, or other repositories 130d. In some examples, the source code repository 130a stores the source code and changes to the source code of a software program, while the platform configuration database 130b stores platform configurations or platform configuration data for the computing platform on which the software program is developed and / or deployed (and executed). The artifact repository 130c stores build artifacts, configuration files (e.g., platform configurations), and other data consumed by components in the software development system 105 and / or the software deployment system 140. In some examples, source code (e.g., C, C++) is compiled or converted into a binary or executable file containing machine code or binary code. The binaries of the software development pipeline 110 and the software deployment pipeline 145 are themselves artifacts and are stored in the artifact repository 130c. In addition, changes to the source code are also stored in the source code repository 130a, which manages the change history of the source code using a source control system (e.g., Git). When the software development pipeline 110 accesses (e.g., receives or pulls) the code from this source code repository 130a, the software development pipeline 110 accesses a specific version defined within the pipeline configuration. In one example, the source code repository 130a, the platform configuration database 130b, the artifact repository 130c, or other repositories 130d are separate databases. In another example, two or more of the source code repository 130a, the platform configuration database 130b, the artifact repository 130c, or other repositories 130d are part of the same database.In yet another example, the source code repository 130a, the platform configuration database 130b, the artifact repository 130c, or another repository 130d are each part of the same database.

[0022]

[0026] System 100 further includes a software deployment system 140 (also called the “Release System” or “Continuous Deployment (CD) System”) which includes a software deployment pipeline 145 (also called the “Release Pipeline”). In some cases, the software deployment system 140 may include APIs for deploying software programs to virtual resources such as virtual machines (“VMs”) and container orchestration systems (e.g., Kubernetes® container orchestration systems). The software development system 105, one or more data storage devices 130, and the software deployment system 140 may be located within networks 135a, 135b, and 135c, respectively. In some examples, the software development system 105, one or more data storage devices 130, and the software deployment system 140 are distributed across multiple networks within networks 135a, 135b, and 135c. In one example, the software development system 105, one or more data storage devices 130, and the software deployment system 140 are located within the same network 135. In another example, the software development system 105, one or more data storage devices 130, and the software deployment system 140 are located within different networks 135a, 135b, and 135c. In yet another example, two of the software development system 105, one or more data storage devices 130, and the software deployment system 140 are located within the same network 135. In some embodiments, user devices 150a-150n access and / or control one or more of the software development system 105 and / or the software deployment system 140, possibly via a user interface ("UI") and via network 135d (which may be an access network, etc.). In one example, networks 135a-135d are the same network. In another example, networks 135a-135d may each be different networks. In yet another example, two or more (but not all) of networks 135a-135d are the same network.

[0023]

[0027] In some examples, the control system 115 includes at least one of a secure computing mode profile generator, a software security system, or a software hardening system. In some examples, the control system 115 may be implemented as a cloud computing system. Networks 135a to 135d (collectively, "Network 135") may each include a distributed computing network such as the Internet, a private network, a commercial network, or a cloud network. In some examples, user equipment 150 includes, each, a desktop computer, a laptop computer, a tablet computer, a smartphone, a mobile phone, or any suitable device capable of communicating with Network 135 or a server or other network device within Network 135. In some examples, user equipment 150 includes, each, any suitable device capable of communicating with at least one of the software development system 105 and / or the control system 115 via a communication interface. The communication interface may include a web-based portal, API, server, software application, or any other suitable communication interface (not shown) on Network 135.

[0024]

[0028] In terms of operation, the software development system 105, the control system 115, the software deployment system 140, and / or the user device 150 (collectively, the "Computation System") can implement methods for implementing automatic runtime execution hardening for software programs under development and / or deployment, as will be described in detail with respect to Figures 2 to 4. For example, the data flows described below with respect to Figures 2 and 3 can be applied to the operation of system 100 in Figure 1.

[0025]

[0029] Figure 2 shows a block diagram illustrating an exemplary data flow 200 for implementing automated runtime execution hardening for software programs under development and / or deployment. In Figure 2, the computing system 205 includes a control system 115 and / or user equipment 150. In the exemplary data flow 200 of Figure 2, the software development pipeline 210a, control system 115, source code repository 130a, platform configuration database 130b, artifact repository 130c, software deployment pipeline 210b, and user equipment 150 may be similar, if not identical, to the software development pipeline 110, control system 115, source code repository 130a, platform configuration database 130b, artifact repository 130c, software deployment pipeline 145, and user equipment 150a-150n of system 100 in Figure 1. The descriptions of these components of system 100 in Figure 1 are similarly applicable to the corresponding components in Figure 2.

[0026]

[0030] Referring to the exemplary data flow 200 in Figure 2, the computing system 205 interacts with or interfaces with each of the following: the software development pipeline 210a (including or providing a software development environment), the software deployment pipeline 210b (including or providing a software deployment environment), the source code repository 130a, the platform configuration database 130b, and the artifact repository 130c. Specifically, in operation 215, the computing system 205 accesses (e.g., receives or pulls) the source code of a software program from the source code repository 130a, and in operation 220, stores (e.g., pushes) code changes on the source code repository 130a. In operation 225b, the computing system 205 stores in the artifact repository 130c a platform configuration that can be configured by the user and stored in the platform configuration database 130b (and accessed from there in operation 225a). In operation 230, the computing system 205 triggers a software build process 235 in which the source code of a software program is compiled to create an executable software program, or the source code of a software program is converted into an executable programming language or scripting language without compilation into a machine language program. During the software build process 235, in operation 240, the platform configuration is accessed from the artifact repository 130c, and artifacts used and / or generated during the build process are stored in the artifact repository 130c in operation 245.

[0027]

[0031] In operation 250, the computing system 205 triggers a profile generation process 255, which runs within the software development pipeline 210a along with the software build process 235. During the profile generation process 255, artifacts are accessed from the artifact repository 130c (in operation 260), platform-specific configurations are read from or accessed from the artifact repository 130c (in operation 265), and the resulting profile artifacts (e.g., artifacts of platform-specific enforced profiles generated by the profile generation process 255) are stored in the artifact repository 130c (in operation 270). The profile generation process 255 is described in more detail below with respect to the data flow 300 in Figure 3.

[0028]

[0032] In operation 275, the computing system 205 triggers a deployment process 280 that runs within the software deployment pipeline 210b. In one example, the software deployment pipeline 210b is separate from the software development pipeline 210a. In another example, the software deployment pipeline 210b and the software development pipeline 210a are part of a single pipeline (e.g., a CI / CD pipeline). During the deployment process 280, in operation 285, artifacts containing profiles (e.g., platform-specific enforcement profiles) are accessed from the artifact repository 130c. In operation 290, the deployment process 280 further includes hardening the software program by applying the profiles to the software program, and deploying the hardened software program to, for example, an on-premises VM 295a, a cloud VM 295b, and / or a container runtime interface ("CRI") 295c. In some examples, CRI295c includes container orchestration systems (e.g., the Kubernetes® container orchestration system) and / or container systems without orchestration (e.g., the Docker® container platform). When applied to a software program, the profile defines the actions that the software program is allowed to perform while blocking any other actions, thereby protecting the system in which the software program is deployed.

[0029]

[0033] Figure 3 shows a block diagram illustrating an exemplary data flow 300 for implementing automated runtime execution hardening for a software program. Figure 3 details the processes that occur during the profiling process 255 in Figure 2. In the exemplary data flow 300 of Figure 3, the control system 115, user device 150, computing system 205, artifact repository 130c, software development pipeline 210a, and profiling process 255 may be similar, if not identical, to the control system 115, user device 150, computing system 205, artifact repository 130c, software development pipeline 210a, and profiling process 255 of the exemplary data flow 200 of Figure 2. The descriptions of these components in the exemplary data flow 200 of Figure 2 can be similarly applied to the corresponding components in Figure 3.

[0030]

[0034] Referring to the exemplary data flow 300 in Figure 3, the computing system 205 triggers a profiling process 255, which is executed within the software development pipeline 210a, in operation 305. As shown in the exemplary data flow in Figure 2, the software build process 235 is also executed within the software development pipeline 210a. During the profiling process 255, a process 310 for static analysis of the artifact is executed, during which the artifact is accessed from the artifact repository 130c (in operation 315) and system API usage data 325 is output (in operation 320). The process 310 for static analysis of the artifact is performed without executing the software program. The process 310 may further include analyzing the machine code (and / or binary) of the software program to scan and map all possible control flow paths. In some examples, the scanning and mapping of possible control flow paths may include starting from each entry point of the main part of the machine code contained in the artifact and any libraries it uses, until each of the multiple control flow paths in the machine code has been scanned and mapped. A Control Flow Generator (CFG) can be generated based on scanning and mapping possible control flow paths. In an example, the CFG is used to identify system call invocations in the possible code paths of a software program. In some examples, system API usage data is generated based on identified system call invocations in the (respective) possible code paths of a software program.

[0031]

[0035] In some cases, the analysis process (in operation 310) is performed using a software development tool (e.g., Sysfilter). Generally, a software development tool is a computer program used during software development to create, debug, maintain, or support other programs and applications. In this case, the software development tool reads the machine code within an executable file (e.g., an artifact) and, using the first operation the executable performs at runtime as the entry point, traverses all possible flows within the code from all possible entry points. Often, an executable file has multiple entry points, and the process is repeated from each entry point. After traversing the executable file and its dependencies (e.g., shared libraries, other executables used by the main part of the code), the software development tool creates a CFG. Using the CFG, the software development tool identifies all instances in which the special operation "syscall" is used. A "syscall" is a way for a program to invoke a system call, which is an interface with the operating system. By analyzing the code before the "syscall" is invoked, the software development tool determines what values ​​a certain register can hold. The values ​​in this register determine which system call is being used (e.g., reading a file, sending data over a network, querying information about the operating system). Software development tools compile these values ​​into a list and return it as output. These values ​​are then translated into the names of actual system calls on the relevant platform, and the meaning of each value may vary depending on the kernel version.

[0032]

[0036] In operation 330, the computing system 205 triggers platform-specific enforcement profile creation 335, during which system API usage data 325 is input (in operation 340), platform-specific configuration is read from artifact repository 130c (in operation 345), and platform-specific enforcement profile 355 is output (in operation 350). In some examples, instead of the computing system 205 triggering platform-specific enforcement profile creation 335, platform-specific enforcement profile creation 335 is triggered by receiving or inputting system API usage data 325 (in operation 340) from the output of static analysis of artifacts 310 (in operation 320). The platform-specific enforcement profile 355 is then stored on artifact repository 130c in operation 360. As described above, when an enforcement profile is applied to a software program, it protects the system on which the software program is deployed or executed by defining the actions that the software program is allowed to perform while blocking other actions. The application of forced profiling to the software program can be performed within the software deployment pipeline 210b shown in Figure 2.

[0033]

[0037] In the example, a wrapper function or wrapper function API is used to (a) automatically access artifacts from the artifact repository 130c (in operation 315), (b) implement an analysis tool (in operation 310) for automatically generating system API usage data, and (c) output system API usage data (in operation 320). As used herein, a wrapper function refers to a function or subroutine in a software library or computer program (in this example, in the software development system 105 or the software development pipeline 110 of the software development pipeline 210a or the control system 115). The function or subroutine of the wrapper function is configured to call a second subroutine or to call a system with little or no additional computation, and, referring to the above example, is configured to call an analysis tool or software development tool (e.g., Sysfilter) to perform analysis for generating system API usage data. As used herein, a computer program refers to a program for implementing automatic profile generation, while a software program refers to a program on which profile generation is performed to harden the aforementioned software program.

[0034]

[0038] Figures 4A and 4B illustrate exemplary methods 400 for implementing automated runtime execution hardening for software programs. While the techniques and procedures are depicted and / or described in a specific order for illustrative purposes, it should be understood that certain procedures may be reordered and / or omitted within the scope of various embodiments. The operations of Method 400 can be performed by one or more computing devices, such as those discussed in the various systems described above. In some examples, the operations of Method 400 are performed by a computing device operating as a computing system or software development system.

[0035]

[0039] In the exemplary method shown in Figure 4A, operations 405–430 can be performed within the software development environment of a software development pipeline, where the source code of a software program is compiled to create an executable software program, or the source code of a software program is converted into an executable programming language or scripting language without compilation into a machine language program. Operation 435 may be performed within the production or deployment environment of a software deployment pipeline, where the software program is configured for deployment and ultimately deployed. In the example, these operations are performed by a computing system (e.g., a software development system or a control system for a software development system). In some cases, the software program includes one of the following: a software application, a software package, or an operating system.

[0036]

[0040] In operation 405, the computing system accesses (e.g., receives or pulls) artifacts related to the software program from a data storage device, such as the data storage device 130 in Figures 1 to 3. In the example, the artifacts include executable files, library files, binaries (including machine code), data files, configuration files, data models, deployment scripts, database definitions, or raw data input files in various formats (e.g., JSON, XML, Dat files). In operation 410, the computing system performs a static analysis of the artifacts related to the software program. The static analysis is performed without executing the software program. Method 400 may include, in operation 415, the computing system generating system API usage data based on the static analysis in operation 410.

[0037]

[0041] In one example, the computing system performs a static analysis of artifacts associated with a software program, i.e., without executing the software program, and generates system API usage data based on the static analysis of the artifacts. In another example, the computing system analyzes binaries, in particular, associated with the software program, without executing the software program, and generates system API usage data based on the analysis of the binaries. In yet another example, the computing system analyzes machine code, in particular, associated with the software program, without executing the software program, and generates system API usage data based on the analysis of the machine code. In some cases, the binaries or machine code are stored on a data storage device during or after the creation of the executable software program and can then be accessed from the data storage device for static analysis in operation 410 (if applicable). Figure 4B shows an example of at least one analysis of artifacts or machine code, as detailed below.

[0038]

[0042] In operation 420, the computing system accesses platform configuration data from the data storage device. In some examples, the platform configuration data accessed from the data storage device (in operation 420) is the same platform configuration data used when compiling or transforming the source code of a software program to create an executable software program. In such examples, the platform configuration data is stored on the data storage device during or after the creation of the executable software program and before the artifact is received or accessed from the data storage device in operation 405.

[0039]

[0043] In operation 425, the computing system creates a platform-specific enforcement profile for the secure mode hardening function based on system API usage data (from operation 415) and platform configuration data (from operation 420). Then, in operation 430, the platform-specific enforcement profile is stored on or pushed to data storage. In some examples, accessing artifacts (in operation 405) and accessing platform configuration data (in operation 420) are performed using wrapper function APIs, respectively. When applied to a software program, such as in any operation 435, the platform-specific enforcement profile defines the actions that the software program is allowed to perform while blocking other actions. In this way, the platform-specific enforcement profile protects the system on which the software program is running from potential harm caused by a compromised software program. In some examples, the platform-specific enforcement profile does this by preventing the compromised software program from using any of the blocked system calls or other actions (e.g., accessing sensitive information, modifying files, or making network connections) and by only allowing the use of system calls or other actions defined within the platform-specific enforcement profile.

[0040]

[0044] Referring to Figure 4B, performing a static analysis of the artifact in operation 410 (i.e., analyzing the artifact without executing the software program) may include, in operation 440, analyzing the binary of the software program to scan and map the possible control flow paths. In some examples, scanning and mapping the possible control flow paths may include starting from each entry point of the main part of the machine code contained in the artifact and any libraries it uses, until each of the multiple control flow paths in the machine code has been scanned and mapped. In operation 445, a CFG may be generated based on the scanning and mapping of the possible control flow paths. In an example, in operation 450, the CFG is used to identify invocations of system calls in the possible code paths of the software program. In some examples, generating system API usage data (in operation 415) may include, in operation 455, generating system API usage data based on the identified invocations of system calls in the possible code paths of the software program.

[0041]

[0045] While various embodiments of the full enforcement mode, which blocks unintended calls, have been described, an audit mode may be implemented instead. In audit mode, the hardening profile can monitor and record allowed calls or calls that should be blocked, but does not actually block unintended calls. By enabling the option to switch between full enforcement mode and audit mode, the system can be verified by running in either mode as needed or desired, and can be used to increase confidence in the system for users. As used herein, “unintended call” refers to a call that performs a task that is unintended or contrary to the normal operation of the program or system. For example, during video processing operation, the enforcement profile can prevent system calls such as “clock_adjtime” that change the OS clock time and contradict the intended operation of the video processing program. Since the enforcement profile can operate in several modes, there are different unintended calls for each mode. For example, in an enforcement profile with allowed calls, all calls not on the list of allowed calls are unintended. In contrast, in an enforcement profile with blocked calls, the default action is to allow the call, and therefore dedicated sections with the “SCMP_ACT_ERRNO” notation are blocked. In an enforcement profile with audit mode, all calls are permitted, and the enforcement profile monitors which permitted or denied actions would be blocked if the enforcement profile were enforcing as well as auditing.

[0042]

[0046] Method 400 as shown in Figures 4A and 4B can be implemented by or using the systems, examples, or embodiments 100, 200, and 300 (or their components) in Figures 1, 2, and 3, respectively, but such methods can also be implemented using any suitable hardware (or software) implementation. Similarly, each of the systems, examples, or embodiments 100, 200, and 300 (or their components) in Figures 1, 2, and 3 can operate according to Method 400 as shown in Figures 4A and 4B (for example, by executing instructions embodied on a computer-readable medium), but the systems, examples, or embodiments 100, 200, and 300 in Figures 1, 2, and 3 can also operate according to other operating modes and / or perform other suitable procedures.

[0043]

[0047] Figure 5 shows a block diagram of the physical components (e.g., hardware) of a computing device 500 in which an example of the present disclosure may be put into practice. The computing device components described below may be suitable for a client device that implements the automated runtime execution hardening for software programs under development and / or deployment as discussed above. In a basic configuration, the computing device 500 includes at least one processing unit 502 and system memory 504. The processing unit (e.g., processor) may be called a processing system. Depending on the configuration and type of the computing device, the system memory 504 may include volatile storage (e.g., random access memory), non-volatile storage (e.g., read-only memory), flash memory, or any combination of such memory. To implement one or more of the above systems or methods, the system memory 504 may include an operating system 505 and one or more program modules 506 suitable for running software applications 550 such as an automated profile generation application 551.

[0044]

[0048] The operating system 505 may be suitable, for example, for controlling the operation of the computing device 500. Furthermore, aspects of the present invention may be practiced in conjunction with a graphics library, another operating system, or any other application program, and are not limited to any particular application or system. This basic configuration is shown in Figure 5 by the components within the dashed line 508. The computing device 500 may have additional features or functions. For example, the computing device 500 may also include additional (possibly removable and / or non-removable) data storage devices, such as magnetic disks, optical disks, or tapes. Such additional storage is shown in Figure 5 by removable storage device 509 and non-removable storage device 510.

[0045]

[0049] As described above, several program modules and data files can be stored in system memory 504. While running on processing unit 502, program module 506 can perform processes including one or more operations of the method shown in Figure 4, or one or more operations of the system and / or equipment described with respect to Figures 1 to 3. Other program modules that may be used according to examples of the present invention may include applications such as email and contacts applications, document processing applications, spreadsheet applications, database applications, slide presentation applications, drawing or computer-assisted application programs, AI applications and machine learning ("ML") modules on cloud-based systems.

[0046]

[0050] Furthermore, the examples of the present disclosure can be implemented in electrical circuits including discrete electronic elements, packaged or integrated electronic chips including logic gates, circuits utilizing microprocessors, or on a single chip including electronic elements or a microprocessor. For example, the examples of the present disclosure can be implemented by a system-on-a-chip ("SOC"), in which each or many of the components shown in Figure 5 may be integrated on a single integrated circuit. Such an SOC device may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all of which may be integrated (or "burned") on a chip substrate as a single integrated circuit. When operating by an SOC, the functions described herein with respect to generating the proposed queries may be operated by application-specific logic integrated with other components of the computing device 500 on a single integrated circuit (or chip). The examples of the present disclosure can also be implemented using other techniques capable of performing logical operations such as AND, OR, and NOT, including mechanical, optical, fluid, and / or quantum techniques.

[0047]

[0051] The computing device 500 may also have one or more input devices 512, such as a keyboard, mouse, pen, voice input device, and / or touch input device. It may also include output devices 514, such as a display, speaker, and / or printer. The devices described above are examples, and other devices may be used. The computing device 500 may include one or more communication connections 516 that enable communication with other computing devices 518. Suitable examples of communication connections 516 include radio frequency ("RF") transmitters, receivers, and / or transceiver circuits, universal serial buses ("USB"), parallel and / or serial ports, and the like.

[0048]

[0052] As used herein, the term “computer-readable medium” may include computer storage medium. Computer storage medium may include volatile and non-volatile and / or removable and non-removable media that can be implemented by any method or technique for storing information such as computer-readable instructions, data structures, or program modules. System memory 504, removable storage device 509, and non-removable storage device 510 are all examples of computer storage medium (i.e., memory storage areas). Computer storage medium may include random access memory ("RAM"), read-only memory ("ROM"), electrically erasable programmable read-only memory ("EEPROM"), flash memory or other memory technologies, compact disc read-only memory ("CD-ROM"), digital multipurpose disc ("DVD") or other optical storage areas, magnetic cassettes, magnetic tapes, magnetic disk storage areas or other magnetic storage devices, or any other manufactured products that can be used to store information and are accessible by the computer 500. Any such computer storage medium may be part of the computer 500. Computer storage media can be non-temporary and tangible and do not contain carrier waves or other propagating data signals.

[0049]

[0053] Communication media may be embodied by computer-readable instructions, data structures, program modules, or other data within modulated data signals such as carrier waves or other transport mechanisms, and may include any information distribution medium. The term “modulated data signal” may refer to a signal in which one or more characteristics are set or modified in a manner that encodes information within the signal. For example, communication media may include wired media such as wired networks or direct wired connections, as well as wireless media such as acoustic, RF, infrared, and other wireless media.

[0050]

[0054] In one embodiment, the technology relates to a system. The system includes a processing system and memory coupled to the processing system. The memory includes computer executable instructions that, when executed by the processing system, cause the system to perform operations including performing a static analysis of artifacts related to a software program and generating system application programming interface ("API") usage data based on the static analysis. The operations also include creating a platform-specific enforcement profile for secure mode hardening functionality based on the system API usage data and platform configuration data, the platform-specific enforcement profile defining permitted and blocked requests with respect to the software program. The operations further include storing the platform-specific enforcement profile on a data storage device.

[0051]

[0055] In some embodiments, static analysis includes scanning and mapping possible control flow paths by analyzing the artifact, generating a control flow graph ("CFG") based on the scanning and mapping of possible control flow paths, and using the CFG to identify invocations of system calls in the possible code paths of the software program. In an example, generating system API usage data includes generating system API usage data based on the identified invocations of system calls in the possible code paths of the software program. In an example, scanning and mapping possible control flow paths includes scanning and mapping possible control flow paths starting from each entry point of the main part of the machine code contained in the artifact and any libraries it uses, until control flow paths in the machine code are scanned and mapped.

[0052]

[0056] According to some embodiments, the operation further includes applying a platform-specific enforcement profile to the software program. In one example, applying a platform-specific enforcement profile to the software program causes it to block requests that are not enumerated as permitted.

[0053]

[0057] In some examples, the operation further includes accessing artifacts from data storage and accessing platform configuration data from data storage. In some examples, accessing artifacts includes pulling artifacts from data storage. In some examples, accessing platform configuration data includes pulling platform configuration data from data storage. In one example, storing platform-specific coercion profiles includes pushing platform-specific coercion profiles to data storage. According to some embodiments, pulling artifacts and pulling platform configuration data are performed using wrapper function APIs, respectively. In some examples, platform configuration data is used when compiling or transforming the source code of a software program to create an executable software program, and is stored on data storage during or after the creation of the executable software program and before the artifacts are parsed. In some embodiments, artifacts include at least one of an executable file, library file, binary, data file, configuration file, data model, deployment script, database definition, or input file.

[0054]

[0058] In another aspect, the technology relates to a computer implementation method that includes performing operations within a software development environment in which the source code of a software program is compiled or transformed to create an executable software program. The operations include performing a static analysis of artifacts associated with the software program, generating system application programming interface ("API") usage data based on the static analysis, and creating a platform-specific enforcement profile for secure mode hardening functionality based on the system API usage data and platform configuration data. The platform-specific enforcement profile defines permitted and blocked system calls with respect to the software program. The operations further include storing the platform-specific enforcement profile in a data storage device and applying the platform-specific enforcement profile to the software program within a software deployment environment in which the software program is configured for deployment.

[0055]

[0059] In some cases, the artifact contains machine code, and analyzing the artifact without executing the software program involves analyzing the artifact to scan and map the possible control flow paths, starting from each entry point of the main part of the machine code contained in the artifact and any libraries it uses, until the control flow paths in the machine code are scanned and mapped. Analyzing the artifact further involves generating a control flow graph ("CFG") based on the scanning and mapping of possible control flow paths, and using the CFG to identify invocations of system calls in the possible code paths of the software program. In some cases, generating system API usage data involves generating system API usage data based on the identified invocations of system calls in the possible code paths of the software program.

[0056]

[0060] According to some embodiments, the method further includes accessing artifacts from a data storage device and accessing platform configuration data from a data storage device. In some cases, accessing artifacts includes pulling artifacts from a data storage device. In some cases, accessing platform configuration data includes pulling platform configuration data from a data storage device. In one example, storing platform-specific coercion profiles includes pushing platform-specific coercion profiles to a data storage device. In some embodiments, pulling artifacts and pulling platform configuration data are performed using wrapper function APIs, respectively.

[0057]

[0061] In yet another aspect, the technology relates to a system including a processing system and memory coupled to the processing system. The memory includes computer executable instructions that cause the system to perform operations when executed by the processing system. The operations include generating system application programming interface ("API") usage data based on static analysis of artifacts associated with a software application within a software development environment where the source code of a software application ("app") is compiled or transformed to create an executable software program. The operations also include creating a platform-specific enforcement profile for secure mode hardening functionality based on the system API usage data and platform configuration data, the platform-specific enforcement profile defining permitted and blocked system calls with respect to the software program. The operations further include pushing the platform-specific enforcement profile to a data storage device.

[0058]

[0062] In some embodiments, the operation further includes using a wrapper function API to pull artifact and platform configuration data related to the software application from a data storage device, and performing a static analysis of the artifacts related to the software application. In an example, the data storage device includes an artifact storage device, artifacts are pulled from the artifact storage device, and platform-specific coercion profiles are pushed to the artifact storage device. In some examples, the artifacts include the binary of the software program. In one example, analyzing the artifacts without executing the software program includes analyzing the binary of the software program to scan and map possible control flow paths, generating a control flow graph ("CFG") based on the scanning and mapping of possible control flow paths, and using the CFG to identify invocations of system calls in the possible code paths of the software program. In some examples, generating system API usage data includes generating system API usage data based on the identified invocations of system calls in the possible code paths of the software program.

[0059]

[0063] According to some embodiments, the binary of a software program includes machine code. In some examples, scanning and mapping possible control flow paths includes scanning and mapping possible control flow paths, starting from each entry point of the main portion of the machine code contained in the artifact and any libraries it uses, until a control flow path in the machine code is scanned and mapped.

[0060]

[0064] In this detailed description, the same or similar elements are referred to using the same reference number in the drawings and detailed description whenever possible. In some cases, a sublabel is associated with the reference number to indicate one of several similar components. When a reference number is referred to without specifying an existing sublabel, it is intended to refer to all such several similar components. To indicate multiple components, the suffixes "a" through "n" may be used, where n is any appropriate integer (except when it indicates the number 14, if there are components with reference numbers having suffixes "a" through "m" before a component with a reference number having the suffix "n"), and may be the same as or different from the suffix "n" of other components in the same or different drawings. For example, in components #1 X05a~X05n, the integer value of n in X05n may be the same as or different from the integer value of n in X10n in components #2 X10a~X10n.

[0061]

[0065] Unless otherwise indicated, all numerical values ​​used herein to express quantities, dimensions, etc., should be understood in all cases to be modified by the term "approximately." In this application, the use of singular nouns includes plural nouns unless otherwise specified, and the use of the terms "and" and "or" means "and / or" unless otherwise specified. Furthermore, the use of the term "including" and other forms such as "includes" and "included" should be considered non-exclusive. In addition, terms such as "element" or "component" include both elements and components containing one unit and elements and components containing multiple units unless otherwise specified.

[0062]

[0066] This detailed description includes numerous specific details for illustrative purposes to provide a complete understanding of the embodiments described. However, it will be apparent to those skilled in the art that other embodiments of the invention can be practiced without some of these specific details. In other examples, certain structures and devices are shown in block diagram form. While aspects of the present art may have been described, modifications, adaptations, and other implementations are possible. For example, elements shown in the drawings may be replaced, added, or modified, and methods described herein may be modified by replacing, rearranging, or adding steps to the disclosed methods. Therefore, the detailed description is not intended to limit the present art, and instead the appropriate scope of the present art is defined by the appended claims. Examples may take the form of hardware implementations, entirely software implementations, or implementations combining software and hardware aspects. While several embodiments are described herein, and different embodiments are endowed with various features, it should be understood that features described in relation to one embodiment may also be incorporated into other embodiments. Similarly, a single feature or characteristic of any described embodiment should not be considered essential to all embodiments of the present invention, and other embodiments of the present invention may omit such features. Therefore, the detailed description should not be interpreted as restrictive.

[0063]

[0067] For example, aspects of the present invention have been described above with respect to block diagrams and / or operational diagrams of methods, systems, and computer program products according to aspects of the present invention. Functions and / or actions described within a block may occur outside the order shown in any flowchart. For example, two consecutively shown blocks may actually be executed almost simultaneously, or blocks may sometimes be executed in reverse order depending on the functions and / or actions involved. Furthermore, as used herein and in the claims, the phrase “at least one of element A, element B, or element C” (or any appropriate number of elements) is intended to convey any of elements A, element B, element C, elements A and B, elements A and C, elements B and C, and / or elements A, B, and C (etc.).

[0064]

[0068] The descriptions and explanatory diagrams of one or more embodiments provided in this application are not intended in any way to limit or restrict the scope of the invention as described in the claims. The embodiments, examples, and details provided in this application are considered sufficient to convey possession and to enable others to manufacture and use the best form of the invention as described in the claims. The invention as described in the claims should not be construed as being limited to any embodiments, examples, or details provided in this application. Various features (both structural and methodological), whether shown and described in combination or separately, are intended to be selectively rearranged, included, or omitted to result in an example or embodiment having a particular set of features. With the provision of the descriptions and explanatory diagrams of this application, a person skilled in the art can envision modifications, alterations, and alternative embodiments, examples, and / or similar embodiments that fall within the spirit of a broader embodiment of the general inventive concept practiced in this application, without departing from the broader scope of the invention as described in the claims.

Claims

1. Processing system (502), A memory (504) connected to the processing system (502), which, when executed by the processing system (502), Performing static analysis of artifacts related to software programs (410), Based on the static analysis, generate system application programming interface ("API") usage data (415), Creating a platform-specific enforcement profile for the secure mode hardening function based on the system API usage data and platform configuration data (425), wherein the platform-specific enforcement profile defines the requests that are permitted and blocked with respect to the software program (425), and (430) Storing the platform-specific enforced profile on a data storage device. Memory (504) and a computer executable instruction that causes the system (100) to perform an operation including the above. A system (100) including this.

2. The aforementioned static analysis, By analyzing the aforementioned artifact, possible control flow paths are scanned (440) and mapped. Generating a control flow graph ("CFG") based on the scanning and mapping of possible control flow paths (445), and Using the CFG, identify the invocation of a system call in the possible code path of the software program (450) The generation of the system API usage data includes generating the system API usage data based on the identified calls to the system call in the possible code paths of the software program, The system (100) according to claim 1.

3. The system (100) according to claim 2, wherein the artifact includes machine code, and the scanning and mapping of possible control flow paths includes scanning and mapping possible control flow paths, starting from each entry point of the main portion of the machine code contained in the artifact and any libraries it uses, until a control flow path in the machine code is scanned and mapped.

4. The aforementioned operation, Applying the platform-specific enforcement profile to the software program. The system (100) according to claim 1, further comprising:

5. The system (100) according to claim 4, wherein applying the platform-specific enforcement profile to the software program causes to block requests that are not enumerated as permitted.

6. The aforementioned operation, Accessing the artifact from the data storage device, and Accessing the platform configuration data from the data storage device. The system (100) according to claim 1, further comprising:

7. Accessing the artifact includes pulling the artifact from the data storage device, Accessing the platform configuration data includes pulling the platform configuration data from the data storage device, Storing the platform-specific enforcement profile includes pushing the platform-specific enforcement profile to the data storage device. The system (100) according to claim 6.

8. The system (100) according to claim 7, wherein pulling the artifact and pulling the platform configuration data are performed using wrapper function APIs, respectively.

9. The system (100) according to claim 6, wherein the platform configuration data is used when compiling or converting the source code of the software program in order to create an executable software program, and is stored on the data storage device during or after the creation of the executable software program and before the artifacts are analyzed.

10. The system (100) according to claim 1, wherein the artifact includes at least one of an executable file, a library file, a binary, a data file, a configuration file, a data model, an expansion script, a database definition, or an input file.

11. Within a software development environment where the source code of a software program is compiled or converted to create an executable software program, the following operations, namely: Performing static analysis of artifacts related to the software program (410), Based on the static analysis, generate system application programming interface ("API") usage data (415), Creating a platform-specific enforcement profile for secure mode hardening functionality based on the system API usage data and platform configuration data (425), wherein the platform-specific enforcement profile defines permitted and blocked system calls with respect to the software program (425), and (430) Storing the platform-specific enforced profile in a data storage device. To perform, and Applying the platform-specific enforcement profile to the software program within a software deployment environment configured for deployment. Computer implementation method (400), including.

12. The artifact includes machine code, and the artifact can be analyzed without executing the software program. Analyzing the artifact to scan and map possible control flow paths, starting from each entry point of the main portion of the machine code contained in the artifact and any libraries it uses, until the control flow paths within the machine code are scanned and mapped. To generate a control flow graph ("CFG") based on the scanning and mapping of possible control flow paths, and Using the CFG, identify the invocation of system calls in the possible code paths of the software program. The generation of the system API usage data includes generating the system API usage data based on the identified calls to the system call in the possible code paths of the software program, The computer implementation method (400) according to claim 11.

13. Accessing the artifact from the data storage device, and Accessing the platform configuration data from the data storage device. The computer implementation method (400) according to claim 11, further comprising:

14. Accessing the artifact includes pulling the artifact from the data storage device, Accessing the platform configuration data includes pulling the platform configuration data from the data storage device, Storing the platform-specific enforcement profile includes pushing the platform-specific enforcement profile to the data storage device. The computer implementation method (400) according to claim 13.

15. The computer implementation method (400) according to claim 14, wherein pulling the artifact and pulling the platform configuration data are performed using wrapper function APIs, respectively.

16. Processing system (502), A memory (504) connected to the processing system (502), which, when executed by the processing system (502), In a software development environment in which the source code of a software application ("app") is compiled or converted to create an executable software program, generating system application programming interface ("API") usage data based on static analysis of artifacts related to the software application (415), Creating a platform-specific enforcement profile for secure mode hardening functionality based on the system API usage data and platform configuration data (425), wherein the platform-specific enforcement profile defines permitted and blocked system calls with respect to the software program (425), and Pushing the platform-specific enforcement profile to the data storage device (430) Memory (504) and a computer executable instruction that causes the system (100) to perform an operation including the above. A system (100) including this.

17. The aforementioned operation, Using a wrapper function API, pull the artifact and platform configuration data related to the software application from the data storage device, and Performing the static analysis of the artifacts related to the software application. The system (100) according to claim 16, further comprising:

18. The system (100) according to claim 17, wherein the data storage device includes an artifact storage device, the artifact is pulled from the artifact storage device, and the platform-specific enforcement profile is pushed to the artifact storage device.

19. The artifact includes the binary of the software program, and the artifact can be analyzed without executing the software program. Analyzing the binary of the software program in order to scan and map possible control flow paths, To generate a control flow graph ("CFG") based on the scanning and mapping of possible control flow paths, and Using the CFG, identify the invocation of system calls in the possible code paths of the software program. The generation of the system API usage data includes generating the system API usage data based on the identified calls to the system call in the possible code paths of the software program, The system (100) according to claim 17.

20. The system (100) according to claim 19, wherein the binary of the software program includes machine code, and the scanning and mapping of possible control flow paths includes scanning and mapping possible control flow paths, starting from each entry point of the main portion of the machine code contained in the artifact and any libraries used therein, until a control flow path in the machine code is scanned and mapped.

Images