Computer implementation methods, software construction systems, and computer programs for building trusted executable software (reliability verification of software artifacts)

Abstract

To provide a computer implemented method for verifying reliability of software deliverables, a software construction system, and a computer program product.SOLUTION: There is provided a computer implemented method for constructing reliable and executable software using reliable construction units between which a route is not reliable, the method including steps of: generating, for each reliable construction unit, an identifier for identifying an output of the reliable construction unit, the reliable construction unit also generating a confirmable certificate with a signature containing the identifier; utilizing, for each distributed reliable construction unit, at least one output result of a preceding construction unit among the reliable construction units as an input; verifying that each confirmable certificate with a signature conforms to a pre-determined series of policy rules; and terminating the construction of the reliable and executable software when the verification of one confirmable certificate with a signature among the reliable construction units has failed.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure generally relates to the construction of trusted executable software, and more specifically to a computer-implemented method for constructing trusted executable software using trusted building units, where the path between the building units is not trusted. The present disclosure further relates to a software construction system and a computer program product for constructing trusted executable software using trusted building units.

Background Art

[0002] To cope with more complex IT (Information Technology) environments, often IT environments based on cloud computing environments, building new software at a faster pace than ever remains an invariant challenge for corporate IT organizations. The latest software development and deployment frameworks typically include multiple building and deployment steps, during which different support units may be used. Each step may depend on inputs from one or more previous steps of the building process. Automated audits are widely used today to enforce specific quality and safety requirements at each step. For example, executed tests, minimum acceptable test coverage, number and severity of findings in static security scans, etc.

[0003] However, these automated tests need to blindly trust the results of previous steps, especially that the results of previous tests are still valid or have not been adjusted or both. Further, even if all steps pass, these security measures cannot affect the execution of the deployed software work product (e.g., an executable software application or a part thereof) if the deployed software work product is old and will no longer pass one of the checks.

[0004] Therefore, testing or verifying that deployed software artifacts still comply with previous checks and tests may become nearly impossible. However, this may be crucial for security-related or highly regulated organizations. A naive approach may require periodically re-executing the build and deployment steps, but this is a highly inefficient process and may only slightly improve software quality, reliability, and security compliance.

[0005] Therefore, it would be desirable to redesign the software build process and potentially the deployment process as well, in order to ensure that only trusted and executable software components are built and deployed.

[0006] There are several disclosures regarding computer implementations for building trusted executable software using trusted build units, where the paths between build units are not trusted. Document DE102014222300A1 discloses a method for verifying the trust status of a certificate or key. This method includes the steps of determining the hash value of the certificate or key, determining the host label from the certificate or key, and retrieving the DNS resource record using the host label.

[0007] As another example, document US2019 / 0207957A1 discloses a system and method for enabling and certifying the reliability of hardware systems. To determine whether an IoT system connected to a network environment is compromised, a networked TaaS (Trust-as-a-Service) server receives system data that exhibits various characteristics of the IoT system, and this system data is collected by a software agent installed on the IoT system. The TaaS server can first establish a baseline characteristic profile of the IoT system and then compare the system data subsequently received from the software agent with this baseline characteristic profile to quickly identify any discrepancies between the initially established baseline characteristic profile and the system's current operating characteristics.

[0008] However, such examples either fail to address, or only partially address, the requirement to generate—that is, build—trusted executable software from scratch. Therefore, there may be a need to overcome these limitations, particularly the need to provide a system for building trusted software that operates securely even in cloud computing environments. [Prior art documents] [Patent Documents]

[0009] [Patent Document 1] German Patent Application Publication No. 102014222300 Specification [Patent Document 2] U.S. Patent Application Publication No. 2019 / 0207957 Specification [Overview of the Initiative] [Problems that the invention aims to solve]

[0010] This invention provides computer implementation methods, software construction systems, and computer program products for verifying the reliability of software artifacts. [Means for solving the problem]

[0011] According to one aspect of this disclosure, a computer implementation method for building trusted executable software using trusted build units is provided, wherein the paths between the build units are untrusted. The method may include each trusted build unit generating an identifier for identifying the output of each trusted build unit, and each trusted build unit also generating a signed verifier certificate containing the identifier. The method may also include each distributed trusted build unit using the output of at least one preceding build unit as input, verifying that each signed verifier certificate conforms to a predetermined set of policy rules, and terminating the building of the trusted executable software if verification of the signed verifier certificate of one of the trusted build units fails.

[0012] In another aspect of this disclosure, a software building system may be provided for building trusted executable software using trusted building units. The system includes a processor and memory communicably coupled to the processor, the memory storing program code portions, and when executed, the processor enables each trusted building unit to generate an identifier for identifying the output of each trusted building unit, each trusted building unit also generating a signed verifier certificate containing the identifier. The processor may also be configured to take the output of at least one preceding building unit of each of the distributed trusted building units as input, verify that each signed verifier certificate conforms to a predefined set of policy rules, and terminate the building of the trusted executable software if the verification of the signed verifier certificate of one of the trusted building units fails.

[0013] A proposed computer implementation method for building trusted executable software using trusted build units, where the paths between build units are unreliable, can provide multiple advantages, technical benefits, contributions, or improvements, or both.

[0014] The proposed method and associated systems can ensure that all steps in the build and deployment pipeline, and the build results of each of them, are valid and cannot be undone or altered. This may bring particular benefit to organizations developing software that can deploy entirely new, trusted executable software applications consisting of software artifacts from different sources, deployable under different licensing terms, and available at different stages of their lifetime, using source code components from open-source repositories, other sources, or both.

[0015] The proposed method can enable control over not only the software development process and steps, but also the software's execution, by re-examining security scans or other constraints such as legal requirements or other policy conditions. It can also facilitate software development organizations in remaining compliant with corporate compliance rules, systems, and licensing constraints.

[0016] For both developers and deployment organizations, the proposed method and associated systems may be completely transparent, as they run in the background and are designed to assist developers or deployment control staff.

[0017] By relying on an available key management system, it is not necessary to meet other separate security prerequisites. The proposed method is self-contained and can be configured to perform periodic reverification and security rescans in a fully automated manner to ensure compliance with policy rules even during the deployment phase of the software application.

[0018] Furthermore, the concept proposed here also avoids the need to rebuild the entire trusted executable software that runs the build process in order to determine that the trusted executable software still complies with all rules and regulations. Since the trusted executable software is obtained from a repository and all signed conformity certificates for the trusted executable software (forming the previous build process) are available, checks may be performed on the running software.

[0019] The following describes additional embodiments of the present invention's concept that are applicable to both this method and the system.

[0020] According to a useful embodiment of this method, the signed verifier certificate may be based on an Internet Security Certificate (e.g., X.509) that includes additional verification information. This additional verification information may be stored in the extended version of the Internet Security Certificate in a dedicated additional field of the protocol.

[0021] According to another useful embodiment of this method, verification of a signed verifier certificate may include a standard method for revoking an Internet security certificate, or all trusted build / build units or trusted execution environment units for building trusted executable software may use a standard method for checking for Internet certificate revocation, or both. Thus, the proposed mechanism is not only useful in the building process of trusted executable software, but can also be effectively used in the deployment phase in a secure execution environment.

[0022] According to a preferred embodiment of the present method, the identifier may be the output of each construction unit or the hash value of one of the outputs. Depending on the selected hash mechanism / algorithm, a unique value for each output of each construction unit can be generated. Further, determining the hash value is computationally relatively "inexpensive". That is, only a small amount of computational resources are required for this.

[0023] According to an advantageous embodiment of the present method, generating a signed attestation certificate may also include testing the constructed trusted executable software. Such tests may consist of functional tests, security function tests, license checks, and compatibility with other compliance rules. If the test may fail, the signed attestation certificate is not generated. Thus, there may be no certificate confirming that all test requirements have been met. However, a signed attestation certificate consisting of statements indicating which requirements have been met and which have not may have been generated. In this way, it may be possible to easily and reliably track the deficiencies in development and processes.

[0024] According to any embodiment, the method can also include revalidating the constructed trusted executable software and generating a new associated signed attestation certificate. This may be done for the software being executed, but it may also be done for any software artifact that is not currently in use and can only be stored in an artifact repository. Thus, all available software artifacts (only during execution / deployment or during preparation for execution) can be managed using a reliable process to ensure compliance with regulations, legal requirements, and internal company rules.

[0025] According to a further developed embodiment of the method, the re-verification may be repeated for a plurality of different types of security scans. Thereby, it may be configurable which of the different available types of security scans can be selected for a particular re-verification. Thus, in order to keep the computational cost for such re-verification relatively low, each time the re-verification is planned, a different type of security scan and a round-robin scheme may be selected. Further, on important days such as end-of-year re-verification, special attention may be paid to legal or license requirements, etc.

[0026] According to an interesting embodiment of the method, generating a signed attestation certificate can represent that the output of a trusted build unit can comply with a predefined set of rules, or which rule requirements may not be met, or both. This may be configured in a build-unit-specific manner. That is, different build units may have to comply with different predefined sets of rules.

[0027] According to an advanced embodiment of the method, the predefined set of rules may be stored outside the development framework of which the trusted build unit is a part. Thus, an enterprise-wide or cross-enterprise policy framework or policy repository may be used to control the build process of a trusted executable software application.

[0028] According to another advantageous embodiment, the method can also include terminating the execution of the trusted executable software if any verification or re-verification of the signed attestation certificate fails during the execution stage of the output of the trusted build unit. Thus, the proposed method and system may be advantageous not only for the build process of the trusted executable software, but also for the deployment stage of the software and the expansion of the deployment system.

[0029] Furthermore, embodiments may take the form of a related computer program product accessible from a computer-enabled or computer-readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, the computer-enabled or computer-readable medium may be any device which may include means for storing, communicating, propagating, or carrying a program for use by or in connection with an instruction execution system, apparatus, or device. [Brief explanation of the drawing]

[0030] It should be noted that embodiments of this disclosure are described with reference to different subject matter. In particular, some embodiments are described with reference to method-type claims, while other embodiments are described with reference to apparatus-type claims. However, those skilled in the art will understand from the above and below descriptions that, unless otherwise specified, any combination of features belonging to one type of subject matter, as well as any combination of features relating to different subject matter, in particular, combinations of features of method-type claims and features of apparatus-type claims, are also disclosed herein.

[0031] The aspects defined above and further aspects of this disclosure will become apparent from the embodiments described below, but will not be limited thereto.

[0032] Preferred embodiments of this disclosure will be described, by reference only to the following drawings.

[0033] [Figure 1] A block diagram of an embodiment of the computer implementation method of the present invention for building trusted executable software using trusted build units, wherein the paths between build units are untrusted. [Figure 2] This is a timing diagram or sequence diagram of at least a part of the proposed construction method. [Figure 3] This is a timing or sequence diagram of at least a portion of the test cycle for the software artifacts constructed as a result of the timing diagram in Figure 2. [Figure 4] This is a timing or sequence diagram of an exemplary re-verification procedure. [Figure 5] This is a timing or sequence diagram of an exemplary software development process using the inventive method for building reliable, executable software. [Figure 6] This figure shows the first part of a block diagram of exemplary components of a system that supports a method for building trusted executable software using trusted build units. [Figure 7] This figure shows the second part of the block diagram in Figure 6, which illustrates the components of a system that supports a method for building trusted, executable software. [Figure 8] This is a block diagram of an embodiment of the software construction system of the present invention for building trusted executable software using trusted construction units. [Figure 9] This figure shows an embodiment of the computing system that constitutes the system shown in Figure 8. [Modes for carrying out the invention]

[0034] This specification may use the following terms, terms, or expressions, or combinations thereof.

[0035] The term "trusted executable software" may mean a software artifact, a complete software application, or a software library or its components (e.g., a Docker image). In some cases, the process of building trusted executable software may be guaranteed not to have been compromised by cybersecurity attacks. Therefore, trusted executable software (artifacts) must be temper-free and comply with a predefined set of policy rules.

[0036] The term “trusted build unit” may mean one of the elements or activities / tasks necessary to build trusted executable software or its associated artifacts. A build may control and manage one(s) of the steps involved in building executable software, starting after the source code has been developed. It may also include incorporating additional source code from other repositories and defining dependencies and interfaces with data sources or other systems.

[0037] The term "path between build units" can refer to the physical or logical way in which software artifacts "move" in a stepwise approach to build trusted executable software. Multiple build units may be required to build trusted executable software starting from a source code. Some build units may use the output of preceding build units as input. This can also be interpreted as the path between build units.

[0038] The term "identifier" may also mean a digital value, such as a hash value, that is unique to the object to be identified. The object to be identified may, in this case, be the output of a construction unit.

[0039] The term "output" may refer to anything that can be generated by a build unit. This could be the final build product, an intermediate product in the build pipeline, or additional metadata from the build process.

[0040] The term "signed verifier certificate" may refer to a type of document consisting not only of an identifier but also of statements about the output of a build unit. One potential statement might be that the output of the build unit may comply with currently active policy rules. Another potential statement might describe whether, or to what extent, the output of the build unit complies with security rules. Here, various different statements about the output of the build unit are possible.

[0041] The term "preceding build unit" may refer to a build unit that uses the output of one or more build units that were previously placed in the build pipeline.

[0042] The term “predefined set of policy rules” may mean any compliance, requirements, or security requirements that a software artifact must adhere to in order to be considered trusted executable or trusted deployable software. Therefore, a predefined set of policy rules may control not only the construction process of the software artifact but also its deployment.

[0043] The term "Internet security certificate" may refer to a suite of known security network protocols (IPsec) that can authenticate and encrypt data packets to provide secure encrypted communication between two computers or two components within a computer over a public network, such as an Internet Protocol network. Note that in large-scale cloud computing systems, the Internet Protocol may also be used for internal communication purposes. Therefore, IPsec may also be used in virtual private networks.

[0044] The terms “secure execution environment” or “trusted execution environment” may here mean that computing can be performed in an environment that guarantees code and data protection with respect to confidentiality and integrity. It may also include security features such as isolated execution and the integrity of applications running in conjunction with the secure execution environment, along with the confidentiality of related assets. Hardware security modules may support a secure execution environment.

[0045] The following provides a detailed explanation of the figures. All instructions in the figures are schematic. First, a block diagram of an embodiment of an inventive computer implementation method for building trusted executable software using trusted build units, wherein the paths between build units are untrusted, is shown. Subsequently, further embodiments and embodiments of a software build system for building trusted executable software using trusted build units are described.

[0046] Figure 1 is a block diagram of a preferred embodiment of a computer implementation method 100 for building trusted executable software using trusted build units, where the paths between build units are untrusted. The method includes, in 102, each trusted build unit generating an identifier to identify the output of each trusted build unit, for example, a hash value of the output of each build unit, and each trusted build unit generating a signed verifier certificate containing the identifier. It should also be noted that a single build unit may have more outputs. It should also be noted that the signed verifier certificate may contain statements about the output provided by a particular load unit, in addition to the identifier. It may also consist of statements about compliance with a particular policy rule, etc. Standard security protocols and standard key mechanisms such as PKI (Public Key Infrastructure) may be used to sign the conformity certificate, in addition to other security protocols.

[0047] Method 100 involves, in 104, each of the distributed trusted build units further utilizing at least one output result from an immediate preceding build unit, or a more upstream preceding build unit than the current trusted build unit, as input, and in 106, verifying that each signed verifier certificate conforms to a predefined set of policy rules.

[0048] Finally, method 100 includes terminating the construction of one trusted executable software in a trusted build unit if verification of a signed verifier certificate fails in 108, for example, because it is an untrusted key, or because it is in a revocation process, or because it is an expired certificate. Thus, it may be ensured that the verified software leaves the construction process. The construction process for a particular software artifact may be made impervious to any security attack. Thus, trusted executable software may be loaded into a secure execution or deployment system, or both, without the risk of loading an already compromised software application into a secure execution environment.

[0049] Figure 2 is a timing or sequence diagram of at least a part of the proposed build method 200. The upper block of Figure 2 represents specific stages of the software build process, such as the developer 202, source code repository 204, build pipeline driver 206, key management system 208, build task 210 itself, policy store 212, software artifact repository 214, and certificate store 216.

[0050] The process flow can be described as follows: At 220, developer 202 checks in the source code they have developed to the source code repository 202. At 222, a build job can be triggered from or by the source code repository 204 to start the build pipeline driver 206. This starts the build task 210 at 224.

[0051] First, at 226, the build policy can be received from the policy store 212. Next, at 228, the input is validated, and at 230, the software artifact is created. Then, at 232, the build task 210 receives a signing key (for example, on request). This signs the built software artifact and the signed verifier certificate, abbreviated as "certificate," at 234, and at 236, the certificate is stored in the certificate store 216. Furthermore, at 238, the built software artifact is stored in the artifact repository 214. At 240, upon completion of the build task 210, a "build complete" signal is sent to the build pipeline driver 206. This allows the secure software build process to terminate.

[0052] Figure 3 is a timing or sequence diagram of at least some of the test cycle 300 for the software artifact constructed as a result of the timing diagram in Figure 2. Most of the stages used in Figure 2 have the same reference numbers here as well. Note that test task 302 has been added.

[0053] First, in 304, the build pipeline driver 206 starts test task 302. This then receives the required certificate from certificate repository 216 in 306. Next, test task 302 receives command 308 to retrieve the required source, i.e., from source code repository 204.

[0054] Next, at 310, test task 302 receives other software artifacts from artifact repository 214, similar to the policy (arrow 312). The received input is then validated at 314 and tested at 316 according to the defined test scenario.

[0055] If the test runs successfully, test task 302 receives the signing key at 318 and is able to sign the artifact and certificate at 320. Subsequently, at 322, the certificate is stored in the certificate store, and the test artifact is stored in the artifact repository 214 at 324. At the end of the test process, at 326, test task 302 signals the build pipeline driver that the test has completed successfully.

[0056] An equivalent sequence diagram may depict the security scanning procedure during the deployment process. However, in this case, the build pipeline driver 206 would instead trigger a scan task (not shown) which would execute all the steps of the test task 302. At the end of the security scanning procedure, the scan task would notify the build pipeline driver that the security scan was successfully completed.

[0057] Figure 4 is a timing or sequence diagram of an exemplary re-authentication procedure, or consistent re-validation procedure 400. At 408, the recurring scan trigger unit 402 initiates the re-validation of the built software based on the schedule. The build pipeline driver 206 then initiates the security scan task 404. In response, the security scan task 404 receives the necessary certificates from the certificate repository 216 at 412, the source code from the source code management system 406 at 414, the artifacts to be security scanned from the artifact repository 214 at 416, and the necessary policies from the policy store 212 at 418.

[0058] The security scan task then validates the received input at 420 and performs the scan at 422. Box 424, indicated by a dashed line, distinguishes between the behavior of a failed scan and a successful scan. If the scan fails, a revocation message is stored in the certificate store 216 at 428. If the scan is successful, the certificate is signed at 429 and stored in the certificate store 216 at 430.

[0059] Next, in step 432, the successfully scanned artifacts are signed, and in step 434, the scanned artifacts are stored in the artifact repository 214. Finally, the security scan task 404 completes by sending a "scan complete" message to the build pipeline driver 206.

[0060] Figure 5 is a timing or sequence diagram of an exemplary software development process 500 using the method of the present invention for building trusted executable software. At 512, the deployment trigger mechanism 502 sends a command to the deployment interface 504 to deploy the application version. From there, the command is sent to the policy verification unit 506 to trigger policy verification. At 516, the policy is received from the policy store 212 as requested. At 518, the certificate is received from the certificate store 516.

[0061] Based on this, at 520, the policy verification unit 506 verifies the received input. If the verification is positive, at 522, the policy verification unit 506 sends a start command to the application runtime system 510 to start the selected application. This causes the application runtime environment 510 to start receiving application artifacts, i.e., trusted executable software, from the artifact repository 214 at 523. Furthermore, at 524, the policy verification unit 506 sends a status report to the compliance system 508. This completes the normal deployment process.

[0062] Figure 5 also includes a second case, the continuous monitoring of policies and certificates shown in the dashed box 526. Such continuous monitoring of validation may be performed according to a predefined or periodic schedule. For this purpose, in 528, the policy validation unit 506 receives policies from the policy store 212 and certificates from the certificate repository 216 (step 530). Here again, the input is validated in 532, and in 534, the application is stopped in the event of a validation error. Simultaneously, in 536, the policy validation unit 506 sends a report status to the compliance system 508.

[0063] Figure 6 shows the first portion of an exemplary block diagram of components of system 600 that supports a method for building trusted executable software using trusted build units. The build pipeline driver 602 (compare 206 in Figure 2) requests the necessary source code from the secure code repository 604 and, in 618, triggers individual build and verification steps. These trigger commands are received by the secure execution environment 606. In the context described herein, the secure execution environment 606 includes a build block build task 608, a secure scan task 610, and a test task 612, each of which can consist of multiple individual scans or tests or both. For each of these tasks, there may be a specific dedicated module. On the other hand, the build task 608, the security scan task 610, and the test task 612 obtain cryptographic keys from the key management system 614, in 616, for example, to sign statements incorporated into a conformance certificate.

[0064] On the other hand, build task 608, security scan task 610, and test task 612 are communicating with certificate store 628 (622). Furthermore, these tasks (i.e., 608, 610, and 612) are communicating with artifact repository 626 (620) (compare 214 in Figure 2).

[0065] Furthermore, the dotted line 632 represents the boundary between the construction process in Figure 6 and the unfolding process described in the context of Figure 7.

[0066] Figure 7 shows a second portion of block diagram 700 of Figure 6, illustrating the components of a system that supports a method for building trusted executable software. Here, the boundary between the build process and the deployment process is shown as a dotted line 632.

[0067] When the software runtime is started, the policy validation module 704 retrieves the relevant data from the artifact repository 626, the certificate store, and the policy store 630 (or executes at another time). To this end, the policy validation module 704 or policy validation unit (compared to 506 in Figure 5) receives, upon request, relevant data from the artifact repository 626, certificate store, and policy store, namely software artifacts, (compliant) certificates, and one or more policies (or policy rules).

[0068] Based on this, the verification cycle 706 is initiated based on a trigger from the deployment interface 710. Once positive verification is achieved, the application runtime environment triggers and controls the execution of the trusted executable software in this secure execution environment 702, i.e., the application runtime 708, which also has reports sent to and stored in the compliance system 624. For continuously running trusted executable software (such as operating systems, frameworks, or other infrastructure software near drivers), the verification cycle can be triggered periodically or according to specific events.

[0069] For reasons of completeness, Figure 8 is a more simplified block diagram of an embodiment of a software build system 800 for building trusted executable software using trusted build units. The software build system 800 includes a processor 802 and a memory 804 communicably coupled to the processor 802, the memory 804 storing program code portions, and when executed, the processor 802 generates an identifier to identify the output of each trusted build unit, in particular by each of the trusted build units 806, and each trusted build unit generates a signed verifier certificate containing the identifier.

[0070] The processor 802 can also use the output of at least one preceding build unit as input, and each of the distributed trusted build units can verify that each signed verifier certificate conforms to a predefined set of policy rules, particularly by a dedicated verification module 808, which may also be a component of the trusted build unit 806.

[0071] Furthermore, processor 802 is adapted to terminate the construction of trusted executable software, in particular by a decision module which is also part of trusted construction unit 806, if verification of one of the signed verifier certificates of a trusted construction unit fails.

[0072] It should also be noted that all functional units, modules, and functional blocks may be coupled to each other in a select one-to-one manner so as to be able to communicate with one another for signaling or message exchange. This applies in particular to the processor 802, memory 804, trusted build unit 806, verification module 808, and termination module 810. Alternatively, functional units, modules, and functional blocks may be linked (i.e., connected) to the system internal bus system 812 for selective signaling or message exchange.

[0073] Embodiments of the present disclosure may be implemented with substantially any type of computer, regardless of the platform suitable for storing, executing, or both program code. Figure 9 shows, as an example, a computing system 900 suitable for executing program code relating to the proposed method.

[0074] Computing system 900 is merely an example of a suitable computer system, and whether or not computer system 900 can perform any or both of the functions defined herein, it is not intended to imply any limitation on the scope or functionality of the embodiments of this disclosure described herein. Computer system 900 contains components that can operate in numerous other general-purpose or dedicated computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, suitable for use with computer system / server 900 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable home appliances, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices. Computer system / server 900 may be described in the general context that computer system executable instructions, such as program modules, are executed by computer system 900. Generally, a program module may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. The computer system / server 900 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules may reside on both local and remote computer system storage media, including memory storage devices.

[0075] As shown in the figure, the computer system / server 900 is represented in the form of a general-purpose computing device. The components of the computer system / server 900 may include, but are not limited to, one or more processors or processing units 902, system memory 904, and a bus 906 that connects various system components, including the system memory 904, to the processor 902. The bus 906 represents one or more of several types of bus structures, including a memory bus or memory controller, peripheral buses, accelerated graphics ports, and processor or local buses using any of the various bus architectures. Examples, but not limited to, such architectures include the Industry Standard Architecture (ISA) bus, Microchannel Architecture (MCA) bus, Extended ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus. The computer system / server 900 typically includes various computer system-readable media. Such media may be any available media accessible by the computer system / server 900 and may include both volatile and non-volatile media, and removable and non-removable media.

[0076] The system memory 904 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 908 or cache memory 910 or both. The computer system / server 900 may further include other removable / non-removable, volatile / non-volatile computer system storage media. A storage system 912 for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, typically referred to as a “hard drive”) may be provided, for illustrative purposes only. A magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”) and an optical disk drive for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media, may also be provided, though not shown. In such cases, each may be connected to the bus 906 by one or more data medium interfaces. As further described and explained below, the memory 904 may include at least one program product having a set of program modules (e.g., at least one) configured to perform the functions of the embodiments of this disclosure.

[0077] A program / utility having a set (at least one) of program modules 916 may, for example, be stored in memory 904, along with an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may include an implementation of a networking environment. The program modules 916 generally perform functions or methodologies, or both, of the embodiments of this disclosure as described herein.

[0078] The computer system / server 900 may communicate with one or more external devices 918 such as a keyboard, pointing device, or display 920, one or more devices that enable a user to interact with the computer system / server 900, or any device (e.g., a network card, modem, etc.) or a combination thereof that enables the computer system / server 900 to communicate with one or more other computing devices. Such communication may occur via the input / output (I / O) interface 914. The computer system / server 900 may also communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via the network adapter 922. As depicted, the network adapter 922 may communicate with other components of the computer system / server 900 via the bus 906. It should be understood that other hardware or software components or combinations thereof, not shown in the illustration, may be used with the computer system / server 900. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0079] Furthermore, a software build system 800 for building trusted executable software using trusted build units may be mounted on the bus system 906.

[0080] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be exhaustive or limit the disclosed embodiments. It will be apparent to those skilled in the art that many modifications and changes are possible without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to describe the principles of the embodiments, their practical application to market-based technologies or technical improvements, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0081] This disclosure may be embodied as a system, method, or computer program product or a combination thereof. The computer program product may include a computer-readable storage medium storing computer-readable program instructions for causing a processor to perform aspects of this disclosure.

[0082] The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system for propagation. Examples of computer-readable media include semiconductor memory or solid-state memory, magnetic tape, removable computer diskettes, random-access memory (RAM), read-only memory (ROM), rigid magnetic disks, and optical disks. Current examples of optical disks include compact disk read-only memory (CD-ROM), compact disk read / write (CD-R / W), DVD, and Blu-ray-Disc.

[0083] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. Examples of computer-readable storage media may be electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or appropriate combinations thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROM, DVD, memory stick, floppy disk, punch cards, or grooved raised structures, and mechanically encoded devices on which instructions are recorded, and appropriate combinations thereof. Computer-readable storage devices as used herein should not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0084] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computer device / processor. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, LAN, WAN, or wireless network, or a combination thereof). The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers or edge servers, or a combination thereof. A network adapter card or network interface within each computer device / processor receives computer-readable program instructions from the network and transfers them for storage in a computer-readable storage medium in the respective computer device / processor.

[0085] The computer-readable program instructions for performing the operations of this disclosure may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and traditional procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions are executable as a standalone software package, either entirely on the user's computer or partially on the user's computer. Alternatively, they may be executable partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including LANs and WANs, or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), and programmable logic arrays (PLAs), can execute computer-readable program instructions by utilizing state information of computer-readable program instructions in order to customize the electronic circuits for the purpose of performing aspects of the present disclosure.

[0086] Aspects of this disclosure are described herein by reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. Each block in a flowchart or block diagram, or both, and any combination of blocks in a flowchart or block diagram, or both, can be executed by computer-readable program instructions.

[0087] The above computer-readable program instructions may be provided to a processor of a general-purpose computer, a dedicated computer, or other programmable data processing device for the purpose of producing a machine. This creates a means for these instructions, executed via the processor of such computer or other programmable data processing device, to perform functions / operations identified in one or more blocks in a flowchart or block diagram, or both. The above computer-readable program instructions may further be stored in a computer-readable storage medium that can be instructed to function in a particular manner to a computer, a programmable data processing device, or other device, or a combination thereof. This constitutes a product in which the computer-readable storage medium containing the instructions includes instructions for performing functions / operations identified in one or more blocks in a flowchart or block diagram, or both.

[0088] Alternatively, a computer execution process may be generated by loading computer-readable program instructions into a computer, another programmable device, or other device, and having a series of operational steps executed on that computer, other programmable device, or other device. This ensures that the instructions executed on the computer, other programmable device, or other device perform functions / operations identified in one or more blocks in a flowchart, block diagram, or both.

[0089] The flowcharts, block diagrams, or both in the drawings of this disclosure illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions for performing a particular logical function. In some other implementations, the functions shown within a block may be executed in an order different from the order shown in each figure. For example, two consecutively shown blocks may actually be executed substantially simultaneously, or in some cases in reverse order, depending on the functions they relate to. Each block in a block diagram or flowchart, or both, and combinations of multiple blocks in a block diagram or flowchart, or both, are executable by a dedicated hardware-based system that performs a particular function or operation, or executes a combination of dedicated hardware and computer instructions.

[0090] The terms used herein are for the sole purpose of describing specific embodiments and are not intended to limit the disclosure. Where used herein, the singular forms "a," "an," and "the" are intended to include the plural form unless the context explicitly indicates otherwise. Where used herein, the terms "comprises" or "comprising" or both specify the presence of a described feature, integer, step, operation, element, or component or combination thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups or combinations thereof.

[0091] All means or step-plus-function structures, materials, actions, and equivalents in the following claims are intended to include any structures, materials, or actions to perform a function in combination with other claimed elements, as specifically claimed. The descriptions in this disclosure are provided for illustrative and explanatory purposes and are not intended to exhaust or limit the disclosure in the disclosed form. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of this disclosure. The embodiments are selected and described to best illustrate the principles and practical applications of this disclosure and to enable others skilled in the art to understand the disclosure in various embodiments with various modifications to suit a particular intended use.

[0092] The inventive concepts of this disclosure can be summarized in the following items and a list of non-limiting embodiments. Example 1 is a computer implementation method for building trusted executable software using trusted build units, wherein the paths between the build units are not trusted. The method includes each trusted build unit generating an identifier to identify the output of each trusted build unit, each trusted build unit also generating a signed verifier certificate containing the identifier, each distributed trusted build unit using the output of at least one preceding build unit of the trusted build unit as input, verifying that each signed verifier certificate conforms to a predefined set of policy rules, and terminating the building of the trusted executable software when verification of one of the signed verifier certificates of a trusted build unit fails.

[0093] Example 2 involves the method according to Example 1, where the signed verifier certificate is based on an Internet Security Certificate that includes additional verification information.

[0094] Example 3 includes the method according to Example 1 or 2, where the verification of the signed verifier certificate is based on the standard method for revoking Internet security certificates, or all trusted build units or trusted execution environment units for building trusted software use the standard method for checking Internet certificate revocation, or both.

[0095] Example 4 includes a method, as in one of the previous examples, where the identifier is the hash value of the output of each build unit.

[0096] Example 5 involves generating a signed verifier certificate, which also includes testing the built trusted executable software, using one of the methods described in the previous examples.

[0097] Example 6 includes methods from either of the previous examples, which also involve re-verifying the built trusted executable software and generating a new, associated signed verifier certificate.

[0098] Example 7 includes the method described in Example 6, where reverification is repeated for multiple different types of security scans.

[0099] Example 8 involves generating a signed verifier certificate, which represents that the output of a trusted build unit conforms to a predefined set of rules, using one of the methods described in the previous examples.

[0100] Example 9 includes the method according to Example 8, in which a predefined set of rules is stored outside of the development framework, of which the trusted build unit is part.

[0101] Example 10 includes a method according to any of the examples above, and further includes terminating the execution of the trusted executable software if the verification of any of the signed verifier certificates fails during the execution phase of the output of the trusted build unit.

[0102] Example 11 includes a software build system for building trusted executable software using trusted build units, wherein the paths between build units are untrusted. The system includes a processor and memory communicably coupled to the processor, the memory storing program code portions, and when executed, the processor enables each trusted build unit to generate an identifier for identifying the output of each trusted build unit, each trusted build unit also to generate a signed verifier certificate containing the identifier, each distributed trusted build unit to utilize the output of at least one preceding build unit as input, each signed verifier certificate to verify that it conforms to a predefined set of policy rules, and the build of trusted executable software to terminate upon failure of verification of one of the signed verifier certificates of a trusted build unit.

[0103] Example 12 includes a system according to Example 11, where the signed verifier certificate is based on an Internet Security Certificate that includes additional verification information.

[0104] Example 13 includes a system according to Example 11 or 12 in which the verification of signed verifiable certificates is based on the standard method for revoking Internet security certificates, or all trusted build units or trusted execution environment units for building trusted software use the standard method for checking Internet certificate revocation, or both.

[0105] Example 14 includes a system, as in any of Examples 11 through 13, where the identifier is the hash value of the output of each build unit.

[0106] Example 15 includes a system, as described in any of Examples 11 through 14, which generates signed verifier certificates and also tests the built trusted executable software.

[0107] Example 16 includes a system according to any of Examples 11 through 15, in which the processor is also adapted to re-verify the built trusted executable software and generate the associated new signed verifier certificate.

[0108] Example 17 includes the system described in Example 16, where reverification is repeated for multiple different types of security scans.

[0109] Example 18 includes a system, as in any of Examples 11 through 17, in which generating a signed verifier certificate signifies that the output of a trusted build unit conforms to a predefined set of rules.

[0110] Example 19 includes a system according to any of Examples 11 through 18, in which the processor is also adapted to terminate the execution of trusted executable software if the verification of any of the signed verifier certificates fails during the execution phase of the output of the trusted build unit.

[0111] Example 20 is a computer program product for building trusted executable software using trusted build units, wherein the paths between the build units are not trusted. The computer program product includes a computer-readable storage medium implementing program instructions, which are executable by one or more computing systems or controllers, and which includes each of the trusted build units generating an identifier to identify the output of each trusted build unit, each trusted build unit also generating a signed verifier certificate containing the identifier, and each of the distributed trusted build units using the output of at least one preceding build unit as input, verifying that each signed verifier certificate conforms to a predefined set of policy rules, and terminating the building of the trusted executable software if verification of one of the signed verifier certificates of a trusted build unit fails.

Claims

1. A computer implementation method for building trusted executable software using trusted build units, wherein the paths between the build units are untrusted, and the method is Each trusted build unit generates an identifier for identifying the output of each trusted build unit, wherein each trusted build unit also generates a signed verifier certificate containing the identifier. Each of the trusted build units utilizes at least one output result of a preceding build unit as input. Each of the aforementioned signed confirmation certificates is verified to conform to a predefined set of policy rules, The build of the trusted executable software is terminated when the verification of one of the signed verifier certificates of the trusted build unit fails, The aforementioned signed verifier certificate is a computer implementation method based on an Internet security certificate containing additional verification information.

2. A computer implementation method for building trusted executable software using trusted build units, wherein the paths between the build units are untrusted, and the method is: Each trusted build unit generates an identifier for identifying the output of each trusted build unit, wherein each trusted build unit also generates a signed verifier certificate containing the identifier. Each of the trusted build units utilizes at least one output result of a preceding build unit as input. Each of the aforementioned signed confirmation certificates is verified to conform to a predefined set of policy rules, The build of the trusted executable software is terminated when the verification of one of the signed verifier certificates of the trusted build unit fails, A computer implementation method in which the verification of the signed verifier certificate is based on the revocation of an Internet security certificate, and all trusted build units or trusted execution environment units for running the trusted executable software use a standard method for checking for Internet certificate revocation.

3. A computer implementation method for building trusted executable software using trusted build units, wherein the paths between the build units are untrusted, and the method is Each trusted build unit generates an identifier for identifying the output of each trusted build unit, wherein each trusted build unit also generates a signed verifier certificate containing the identifier. Each of the trusted build units utilizes at least one output result of a preceding build unit as input. Each of the aforementioned signed confirmation certificates is verified to conform to a predefined set of policy rules, In the event of a failure to verify one of the signed verifier certificates of the trusted build unit, the build of the trusted executable software is terminated. Re-verifying the built trusted executable software, This includes generating a new signed verifier certificate, The aforementioned re-verification is repeated for multiple different types of security scans, according to a computer implementation method.

4. A software build system for building trusted executable software using trusted build units, wherein the paths between the build units are untrusted, and the system is The system includes a processor and a memory communicatively coupled to the processor, wherein the memory stores a program code portion, and when the program code portion is executed, the processor... Each of the trusted build units generates an identifier for identifying the output of the respective trusted build unit, and each of the trusted build units also generates a signed verifier certificate containing the identifier. Each of the trusted build units utilizes at least one output result of a preceding build unit as input. Each of the aforementioned signed confirmation certificates is verified to conform to a predefined set of policy rules, This enables the termination of the build of the trusted executable software when the verification of one of the signed verifier certificates of the trusted build unit fails, The aforementioned signed verification certificate is a software building system based on an internet security certificate that includes additional verification information.

5. A software build system for building trusted executable software using trusted build units, wherein the paths between the build units are untrusted, and the system is The system includes a processor and a memory communicatively coupled to the processor, wherein the memory stores a program code portion, and when the program code portion is executed, the processor... Each of the trusted build units generates an identifier for identifying the output of the respective trusted build unit, and each of the trusted build units also generates a signed verifier certificate containing the identifier. Each of the trusted build units utilizes at least one output result of a preceding build unit as input. Each of the aforementioned signed confirmation certificates is verified to conform to a predefined set of policy rules, This enables the termination of the build of the trusted executable software when the verification of one of the signed verifier certificates of the trusted build unit fails, The verification of the aforementioned signed verifier certificate is based on the revocation of an Internet security certificate, and all trusted build units or trusted execution environment units for running the trusted executable software use standard methods for checking for Internet certificate revocation in the software build system.

6. A software build system for building trusted executable software using trusted build units, wherein the paths between the build units are untrusted, and the system is The system includes a processor and a memory communicatively coupled to the processor, wherein the memory stores a program code portion, and when the program code portion is executed, the processor... Each of the trusted build units generates an identifier for identifying the output of the respective trusted build unit, and each of the trusted build units also generates a signed verifier certificate containing the identifier. Each of the trusted build units utilizes at least one output result of a preceding build unit as input. Each of the aforementioned signed confirmation certificates is verified to conform to a predefined set of policy rules, In the event of a failure to verify one of the signed verifier certificates of the trusted build unit, the build of the trusted executable software is terminated. Re-verifying the built trusted executable software, It is possible to generate a new signed verifier certificate related to this, The aforementioned re-verification is repeated against multiple different types of security scans in a software build system.

7. A computer program for building trusted executable software using trusted build units, wherein the paths between the build units are untrusted, the computer program includes program instructions, the program instructions are executable by one or more computing systems or controllers, and the one or more computing systems Each of the trusted build units generates an identifier for identifying the output of the respective trusted build unit, and each of the trusted build units also generates a signed verifier certificate containing the identifier. Each of the trusted build units utilizes at least one output result of a preceding build unit as input. Each of the aforementioned signed confirmation certificates is verified to conform to a predefined set of policy rules, When the verification of one of the signed verifier certificates of the trusted build unit fails, the build of the trusted executable software is terminated, The aforementioned signed verification certificate is a computer program based on an Internet security certificate that includes additional verification information.

8. A computer program for building trusted executable software using trusted build units, wherein the paths between the build units are untrusted, the computer program includes program instructions, the program instructions are executable by one or more computing systems or controllers, and the one or more computing systems Each of the trusted build units generates an identifier for identifying the output of the respective trusted build unit, and each of the trusted build units also generates a signed verifier certificate containing the identifier. Each of the trusted build units utilizes at least one output result of a preceding build unit as input. Each of the aforementioned signed confirmation certificates is verified to conform to a predefined set of policy rules, When the verification of one of the signed verifier certificates of the trusted build unit fails, the build of the trusted executable software is terminated, The verification of the aforementioned signed verifier certificate is based on the revocation of an Internet security certificate, and all trusted build units or trusted execution environment units for running the trusted executable software use standard methods for checking for Internet certificate revocation in computer programs.

9. A computer program for building trusted executable software using trusted build units, wherein the paths between the build units are untrusted, the computer program includes program instructions, the program instructions are executable by one or more computing systems or controllers, and the one or more computing systems Each of the trusted build units generates an identifier for identifying the output of the respective trusted build unit, and each of the trusted build units also generates a signed verifier certificate containing the identifier. Each of the trusted build units utilizes at least one output result of a preceding build unit as input. Each of the aforementioned signed confirmation certificates is verified to conform to a predefined set of policy rules, In the event of a failure to verify one of the signed verifier certificates of the trusted build unit, the build of the trusted executable software is terminated. Re-verifying the built trusted executable software, This involves generating a new, related, signed, and verifiable certificate. Have them do it, The aforementioned re-verification is repeated against multiple different types of security scans in a computer program.

Images