System for signing software artifacts

Abstract

A system for signing software artifacts is proposed. The system comprises a software repository for storing one or more software artifacts, a monitoring unit for monitoring the software repository, and a signing unit for signing a software artifact. The monitoring unit is configured to send an initiation signal to the signing unit after a new software artifact is stored in the software repository, and the signing unit is configured to sign the newly stored software artifact based on the initiation signal. This makes it possible to sign a software artifact after it has been created and saved. This has the advantage that signing can be integrated into various, including existing, structures for creating software artifacts, since it is not performed during the creation process as in existing systems and therefore does not need to be integrated into the creation process itself.

Description

[0001] The present invention relates to a system for signing software artifacts. Furthermore, the present invention relates to a method for signing software artifacts. Furthermore, the present invention relates to a computer program product that initiates the execution of the method for signing software artifacts on a program-controlled device.

[0002] Software artifacts, i.e., software containers created during a software development process, can be, for example, container images. Software artifacts, such as container images, have the advantage of containing a software application within the container, along with the necessary resources, such as program code, libraries, data, and / or other programs. A container image represents an immutable package of this data and is executable in its own right. Software artifacts, especially container images, encapsulate the software application running in the container from the underlying host system.

[0003] Software applications, or the services provided by software applications, are now implemented using container images in many areas, such as industrial automation and process control, as well as applications in transport systems and vehicles. The IT systems underlying the application areas can be easily and flexibly adapted to new requirements by using container images, as these container images contain all the necessary data and information and are capable of running independently. This allows IT systems to be easily expanded and updated.

[0004] However, this flexibility provided by easily loadable container images brings with it the threat that manipulated or malicious container images can be introduced into the corresponding system and compromise it.

[0005] The provenance, or authenticity, and integrity of container images can be ensured using container signatures. These signatures are created at a specific point in the container image development process. In modern development processes, container images are created during the continuous integration and continuous delivery (CI / CD) process. The signature of the created image also takes place during this process. These images can be uniquely versioned and signed after creation to ensure that the image is exactly the version created.

[0006] However, the signature generated during the development process does not contain any information about the quality of the container image. Systems using the container images therefore currently cannot guarantee certain input quality levels of the container images in addition to their origin, authenticity, and integrity.

[0007] To date, container images have primarily been used unsigned, relying on the trust that the container images stored in a software repository or container registry have not been compromised. For this purpose, a private container registry can be provided that provides the container images and can be subject to access restrictions. Some solutions also use signatures and attach them to the container images to further ensure authenticity and integrity, as described above. Currently, such a signature service, which is directly integrated into a data pipeline used to create container images, is permanently authorized to sign container images without further verification of the container images.Also, any authorized user of a signature service can have any container image or software artifact signed at any time without the service being able to verify whether the artifact in question originates from the correct build process and whether the required security standards are met.

[0008] Such solutions therefore do not allow any reliable conclusions to be drawn about the container image creation process, the so-called software supply chain. This means that the currently used signature service must trust the authorized users and cannot verify whether a software artifact or container image to be signed was actually generated from the designated data pipeline and whether certain security criteria were met. Furthermore, the currently known methods use an authentication process when accessing the signature key, which is often performed with a password and, if necessary, a user name. The necessary credentials for this must be stored within a data pipeline for authentication with the signature service.

[0009] Against this background, one object of the present invention is to provide a way to sign software artifacts in a simple manner, without additional authentication required, while at the same time security criteria of the software artifacts can be checked.

[0010] This object is achieved by the independent claims. Further developments of the invention can be found in the dependent claims.

[0011] Accordingly, a system for signing software artifacts is proposed.

[0012] The system comprises a software repository for storing one or more software artifacts, a monitoring unit for monitoring the software repository, and a signing unit for signing a software artifact.

[0013] A software repository is a managed directory for storing software artifacts. The software repository contains the software artifacts, which can be container images, for example. The software repository can therefore also be a container repository or a container registry. A container registry is a repository or a collection of repositories in which container images can be stored and accessed.

[0014] As explained above, a software artifact is a software container that can contain a software application and the resources required for the software application, such as libraries, program code, or other programs required for its execution. Such a software artifact can, for example, be a container image. The software artifact forms a self-contained unit that can generally function platform-independently.

[0015] The monitoring unit, also called supply chain monitoring, is designed to send an initiation signal to the signing unit after a new software artifact has been saved in the software repository to sign the newly stored software artifact. Unlike previous systems, the software artifact is not signed during the build process, but only after the software artifact has been completed and saved in the software repository. In particular, both the monitoring unit and the signing unit are separate from, or superordinate to, the build process or the data pipeline used for it. The data pipeline therefore has no influence on the signing process and has no knowledge of the signing unit.

[0016] The monitoring unit is therefore preferably a higher-level unit, which in turn prompts the signing unit to sign the newly stored software artifact. The signing unit cannot sign the software artifact without further information, but must first receive an initiation signal from the monitoring unit. In contrast to previously used systems, it is thus possible for the monitoring unit to implement monitoring of the software artifacts stored in the software repository and, based on this monitoring, to initiate the signing of newly stored software artifacts.

[0017] The respective unit, for example, a monitoring unit or a signing unit, can be implemented in hardware and / or software. In a hardware implementation, the respective unit can be embodied as a device or as part of a device, for example, as a computer or a microprocessor or as a control unit on a server or similar device. In a software implementation, the respective unit can be embodied as a computer program product, as a function, as a routine, as part of a program code, or as an executable object.

[0018] In one embodiment, the monitoring unit and the signing unit can be implemented on a common system. In this case, however, it is preferred that the functionalities of the two units be provided separately, and that the monitoring unit is superior to the signing unit and can preferably monitor and / or control it.

[0019] According to one embodiment, after storing the new software artifact in the software repository, the monitoring unit is configured to send information about the release of a signature key for the newly stored software artifact to the signing unit. Furthermore, the signing unit is configured to sign the newly stored software artifact using the released signature key.

[0020] According to this embodiment, the monitoring unit can release a special signature key intended for the software artifact to be signed to the signing unit. This has the advantage that the signing unit is not able to sign any software artifact, but can only sign the newly stored software artifact after the monitoring unit has released the signature key. This introduces a control instance of the signing unit and the software repository.

[0021] According to a further embodiment, the system comprises a key storage unit in which signature keys are stored, wherein the monitoring unit is configured to send information about the authorization of a signature key for the new stored software artifact to the key storage unit, and wherein the signing unit is configured to retrieve the authorized signature key for signing the new stored software artifact from the key storage unit.

[0022] As described above, the signature process is initiated by the monitoring unit. A checksum, e.g., a hash value, of the software artifact to be signed and all information necessary for identification can be passed to the signing unit.

[0023] Furthermore, the monitoring unit can inform the signing unit of the key to be used for signing.

[0024] A plurality of signature keys can be stored in the key storage unit, which can be implemented, for example, by a key vault or a hardware security module. When a new software artifact is stored in the software repository, the monitoring unit can send an authorization signal to the key storage unit to authorize and release a signature key. The signing unit is then able to access this released and authorized key in the key storage unit to sign the software artifact. In this way, several signature keys may already exist, which only need to be released. Creating the required signature key is no longer necessary at this point.

[0025] In one embodiment, the keys can be generated as soon as they are needed, so-called dynamically generated keys. These are then signed by a higher-level key (e.g., an (intermediate) certification authority (CA). The signing unit can thus generate a key pair (private and public key) that is used individually for the respective software artifact and signs this software artifact. After the signature has been generated, the signing unit deletes the private key of the signature key. This has the advantage that an attacker cannot reuse the private key for the software artifact to generate a new signature, because it can only be used once.

[0026] According to a further embodiment, the system comprises a software artifact creation unit, wherein the software artifact creation unit is configured to store the newly stored software artifact in the software repository.

[0027] For example, a developer can initiate a build process to create a software artifact. It should be noted that, regardless of the grammatical gender of a particular term, it includes people with male, female, or other gender identities.

[0028] The build process can be initiated on the software artifact build unit (build infrastructure). A generation pipeline or build pipeline used for this purpose can, for example, be stored in a code repository and operated in the cloud. During this process, the software artifact or container image is built and, if necessary, tests are performed. The exact sequence for this is usually defined within the pipeline definition within the code repository.

[0029] According to a further embodiment, the monitoring unit is configured to monitor the software artifact creation unit. This has the advantage that not only can the storage of a new software artifact be detected and a corresponding signing process initiated by the monitoring unit, but the creation of the software artifact itself is also monitored in the software artifact creation unit.

[0030] The monitoring unit can thus ensure that certain predefined quality levels of the software artifacts are maintained, in addition to the authenticity and integrity of the software artifacts. Furthermore, the monitoring unit can ensure that the signature key is only released when the environments in which the signing takes place—i.e., the signing unit and the software artifact creation unit—have been reviewed for security. The environments should have a defined level of isolation (e.g., with regard to access from the Internet or other networks) that can be assessed by the monitoring unit, and should not have any known security vulnerabilities.

[0031] This can be achieved by the monitoring unit monitoring the software artifact creation unit and other involved units and processes and determining whether certain quality characteristics are met or whether security deficiencies exist. In particular, attacks on the software artifact creation unit and the software repository, as well as the pipelines or supply chains used, can be detected and prevented, or at least their impact mitigated.

[0032] All of these steps and units produce log data, calls to operating system routines (e.g., syscalls), and other changes that can be detected by the monitoring unit. If a cloud solution is used, log data can be stored, for example, within a cloud tenant, to which the monitoring unit has access. Alternatively or additionally, the monitoring unit can also access the API of a code repository of the software artifact creation unit and monitor it. For example, a hash value or similar of the generated software artifact can be generated, which is stored in the log data described above or, for example, in the file system of the software artifact creation unit.The monitoring unit can then compare a hash value or similar of the final software artifact stored in the software repository with the previously stored hash value and thus detect any tampering with the software artifact. If tampering or a quality defect in the creation process chain is detected, the monitoring unit can react accordingly and therefore not initiate the signing of the software artifact and cannot release or authorize a signature key.

[0033] Through the monitoring unit, or its monitoring operations in cooperation with the signing unit, it is thus possible to sign the finished, stored software artifact and, through the signature, to identify a specific quality of the software artifact. Unlike previous systems, the monitoring unit initiates the signing only for the finished, stored software artifact and not by a developer during the creation process. At the same time, however, the entire creation process can be monitored and taken into account during the signature.

[0034] According to a further embodiment, the software repository is configured to send a notification about the new stored software artifact to the monitoring unit after the new stored software artifact has been stored. Alternatively or additionally, the monitoring unit can be configured to retrieve information about new stored software artifacts from the software repository. Depending on the desired configuration, the monitoring unit can thus either actively monitor the software repository or be passively informed about new software artifacts by the software repository.

[0035] According to a further embodiment, the monitoring unit is configured to perform a security check of the software artifact before releasing the signature key. Such a check may, for example, include verifying a checksum (e.g., checksum, hash value) of the software artifact.

[0036] As explained above, the monitoring unit can monitor the software artifact creation unit, and thus also the creation of a software artifact, as well as the signing unit. This provides comprehensive monitoring and control of both the software artifact and the signing process.

[0037] For example, if the monitoring unit receives a message from the software repository about a new software artifact, the monitoring unit can examine the corresponding build process in the build unit and its software artifacts. Alternatively, as described above, the monitoring unit can monitor the software repository and not be informed (so-called polling). In this case, the monitoring unit can actively perform checks on the build unit and / or the software repository cyclically or based on other incoming events, and in particular, detect a new software artifact.

[0038] The monitoring unit can assign the new software artifact to the corresponding creation process and is capable of analyzing the information generated during the creation process, such as log data, calls to operating system routines, etc. The software artifact can be assigned to the creation process, for example, using a checksum (e.g., a hash value) of the generated software artifact. The software artifact itself and its configuration can also be monitored. This allows vulnerabilities and misconfigurations to be identified, and the generated software artifacts to be evaluated.

[0039] Furthermore, a policy can be stored within the monitoring unit to specify the pipeline from which corresponding software artifacts were generated, so that the monitoring unit can, for example, verify whether the software artifact was actually built, whether the generated hash value matches the software artifact within the software repository, and / or whether all required security checks were performed. The applicable security checks can also be stored within the policy. This then leads to an assessment that reflects the security of the creation process as well as the software artifact. This can be used to analyze the individual steps of the pipeline, as well as to verify the security of the underlying infrastructure (e.g.,by matching security groups, performing a vulnerability scan on the systems provided for the software artifact creation unit, ...).

[0040] According to a further embodiment, the monitoring unit is configured to determine a security level of the software artifact and to release a signature key that corresponds to a security level of the software artifact. The software artifacts can have different security levels, which, for example, influence the type of monitoring and verification of the corresponding software artifact. If the software artifact is a software artifact with a high security level, more intensive verifications can be performed than for a software artifact with a lower security level. This assessment of the security level by the monitoring unit can be reflected in the signature process by the monitoring unit authorizing a corresponding signature key that corresponds to the security level that was detected.The advantage here is that the individual pipelines and units do not have to authenticate themselves to a signature service, since the signature process is initiated exclusively by the monitoring unit, including the assessment and evaluation of the security level.

[0041] According to a further embodiment, the monitoring unit is configured to restrict use of the signature key to a predefined period of time. For example, the period of time can correspond to the duration of a signing of the newly stored software artifact. Access to the signature key can be granted to the signing unit only for as long as the signing process lasts, and subsequently, access or release to the signature key can be revoked or removed. This reduces the risk of misuse of the signature key.

[0042] According to a further embodiment, the monitoring unit is designed to monitor the signing unit. The monitoring unit can, in particular, monitor the correct signing of software artifacts by the signing unit. In particular, the monitoring unit can be designed to monitor the use of signature keys by the signing unit and, in the event of unauthorized use of a signature key, to revoke the signature of a software artifact corresponding to the signature key. This can further improve security, since an unauthorized signature can be revoked and the corresponding software artifact can thus be marked as no longer signed. If the software artifact is subsequently to be used by other processes, these processes can recognize that the software artifact is no longer signed and thus refrain from further use, depending on the settings and specifications of the other processes.

[0043] In the event that the software repository cannot permanently store unsigned software artifacts, or in the event that storing unsigned software artifacts causes problems, the software repository can serve as a registry for unsigned software images or have such a separate registry (Development / Dev Registry). In this case, the software repository, or the registry for unsigned software artifacts, should be isolated and secured to prevent the use and transfer of unsigned software artifacts.

[0044] After signing, the signed software artifacts can then be transferred to a target registry, to which general access can be granted. This transfer can be initiated from the target registry or from the software repository, the signing unit, or the monitoring unit. The target registry can be implemented as a separate registry or as part of the software repository.

[0045] According to a further aspect, a method for signing software artifacts is proposed, the method comprising the following steps: monitoring a software repository, storing a new software artifact in the software repository, detecting the storing of the new software artifact or obtaining information about the storing of the new software artifact, sending an initiation signal for signing the new stored software artifact to a signing unit, and signing the new stored software artifact based on the initiation signal.

[0046] Furthermore, a computer program product is proposed which causes the method as explained above to be carried out on a program-controlled device.

[0047] A computer program product, such as a computer program means, can be provided or delivered, for example, as a storage medium, such as a memory card, USB stick, CD-ROM, DVD, or in the form of a downloadable file from a server in a network. This can be done, for example, in a wireless communications network by transmitting a corresponding file with the computer program product or the computer program means.

[0048] The embodiments and features described for the proposed system apply accordingly to the proposed method.

[0049] Further possible implementations of the invention also include combinations of features or embodiments described above or below with respect to the exemplary embodiments that are not explicitly mentioned. In this case, the person skilled in the art will also add individual aspects as improvements or additions to the respective basic form of the invention.

[0050] Further advantageous embodiments and aspects of the invention are the subject of the dependent claims and the exemplary embodiments of the invention described below. The invention will be explained in more detail below using preferred embodiments with reference to the accompanying figures. Fig. 1 shows a schematic block diagram of a system for signing software artifacts; Fig. Figure 2 shows a schematic diagram of the system according to Fig. 1 in a more detailed form; Fig. 3 shows a schematic diagram of a software artifact creation process; and Fig. Figure 4 shows a schematic flow diagram of a method for signing software artifacts.

[0051] In the figures, identical or functionally equivalent elements have been given the same reference numerals unless otherwise stated.

[0052] Fig. Figure 1 shows a system 1 for signing software artifacts. System 1 comprises a software repository 2, a monitoring unit 4, and a signing unit 6. Although the individual units 2, 4, and 6 are shown here as separate units, they can also be implemented in a single computing device. However, even in this case, the functionalities provided by units 2, 4, and 6 are separate, and monitoring unit 4 always provides a higher-level unit with higher-level functionality.

[0053] As in Fig. As can be seen in Figure 1, the software repository 2, the monitoring unit 4, and the signing unit 6 are designed to communicate with each other. Depending on the configuration, this communication can be wireless or wired, for example.

[0054] The monitoring unit 4 is configured to monitor the software repository 2 (S1). If a software artifact is stored in the software repository 2, this is detected by the monitoring unit 4. This detection can occur either passively, in which the software repository 2 sends corresponding information to the monitoring unit 4 (S3), or actively, in which the monitoring unit 4 monitors storage processes in the software repository 2 and thus detects whether a new software artifact has been stored.

[0055] After detecting the storage of a new software artifact, the monitoring unit 4 can send an initiation signal (S4) to the signing unit 6 for signing the new stored software artifact. The initiation signal can also contain information about a signature key to be used.

[0056] Subsequently, the signing unit 6 can sign the new stored software artifact using the signature key in response to the initiation signal (S5).

[0057] In contrast to previous systems, monitoring unit 2 provides a higher-level, central unit that controls and coordinates the signing of software artifacts. Signing is not performed by a developer, but rather by a higher-level entity after the software artifact has been created and saved. This allows system 1 to be integrated into any software artifact creation system (since no integration into the creation process is required; signing takes place afterward). Furthermore, system 1 is capable of performing a neutral review of the created and saved software artifacts, so that the signing allows for a neutral and secure statement about the quality and security of the software artifact.

[0058] With reference to Fig. 2 the signing process and the signing system 1 are described in more detail below.

[0059] As already explained, a software artifact is first created. To do this, a developer 8 starts the creation or build process 12 within a software artifact creation unit 10 (step P1). In previous systems, the developer 8 signs the software artifact at this point (step P1).

[0060] In this embodiment, the monitoring unit 4, in addition to the software repository 2, also monitors the software artifact creation unit 10 and the creation process 12. The monitoring unit 4 can monitor the processes running there, generated log data, operating system calls (e.g., syscalls), etc. In this way, not only the ultimately generated software artifact is monitored in its final state, but also the creation process, which increases the security and trustworthiness of the signing.

[0061] Once the software artifact has been created, it is saved or loaded into the software repository 2 (S2). The monitoring unit 4 can then be informed of the new software artifact (S3) or retrieve this information by monitoring the software repository 2 (S1).

[0062] As already described above, the monitoring unit 4 is configured to initiate the signing of the software artifact (S4) by sending a corresponding signal to the signing unit 6. Additionally, the monitoring unit 4 can send an enable signal P4 to a key storage unit 14 to release a signature key for signing. The signing unit 6 can then retrieve the corresponding key from the key storage unit 14 (P5) and sign the software artifact (S5).

[0063] Thus, monitoring unit 4 can not only monitor software repository 2 and initiate the signing of a software artifact, but is also capable of comprehensive monitoring of the entire system 1, or its units 10, 12, 2, 6, 14. This enables precise and reliable monitoring of the generated software artifact and thus a trustworthy signing of the software artifact. Manipulation of the software artifact can be detected through this comprehensive monitoring, and the signing can be rejected or revoked accordingly.

[0064] As in Fig. As can be seen in Figure 3, in previous systems, the software artifacts are already signed during their creation. This signing can still be performed, with the signing unit 6 performing an additional, higher-level signing process that is centrally controlled and monitored by the monitoring unit 4.

[0065] If a developer 8 starts the development of the software artifact (P1), it is loaded into a software management unit 16 (container orchestration). This software management unit 16 can provide tools and frameworks to manage the creation of the software artifact. The development configuration of the software artifact is transmitted from the software management unit 16 to an approval unit 18 (P6), which reviews this development configuration and returns its approval or rejection of the development configuration to the software management unit 16 (P7). In particular, the approval unit 18 can use approval rules 20 (P8) to review the development configuration of the software artifact. The approval rules 20 can, for example, be CA certificates that guarantee compliance with certain security levels.The information of these CA certificates can then be used by the monitoring unit 4 to determine a security level of a software artifact and to select a corresponding signature key.

[0066] If the development configuration complies with the approval rules 20, the software artifact is accepted and loaded into Software Repository 2 (S2), as described above. Subsequently, the higher-level monitoring and signing process can be performed by Monitoring Unit 4 and Signing Unit 6.

[0067] In Fig. 4 describes by way of example the method for signing a software artifact as it is implemented by the system 1 of Fig. 1 and Fig. 2 is carried out.

[0068] In a first step S1, the software repository 2 is monitored.

[0069] If a new software artifact is stored in the software repository 2 in a second step S2, this can be detected in a third step S3 or, alternatively, information about the storage of the new stored software artifact can be obtained by the monitoring unit 4.

[0070] Subsequently, in a fourth step S4, the monitoring unit 4 sends an initiation signal for signing the new stored software artifact to the signing unit 6. The signing unit 6 then signs the new stored software artifact based on the initiation signal in a fifth step S5.

[0071] As already explained above, this procedure enables a higher-level monitoring and signing of software artifacts, which on the one hand can be integrated into existing processes and systems and on the other hand allows a reliable and trustworthy signing of software artifacts.

[0072] Although the present invention has been described using exemplary embodiments, it can be modified in many ways. List of reference symbols 1 system 2 Software repository 4 Monitoring unit 6 Signing unit 8 developers 10 Software artifact creation unit 12 Software artifact creation process 14 Key storage unit 16 Software management unit 18 approval unit 20 admission rules P1-P8 process steps S1-S5 process steps

Claims

[1] System (1) for signing software artifacts, comprising: a software repository (2) for storing one or more software artifacts, a monitoring unit (4) for monitoring the software repository (2), and a signing unit (6) for signing a software artifact, wherein the monitoring unit (4) is designed to send an initiation signal for signing the new stored software artifact to the signing unit (6) after storing a new software artifact in the software repository (2), and wherein the signing unit (6) is configured to sign the new stored software artifact based on the initiation signal. [2] The system according to claim 1, wherein the monitoring unit (4) is configured to send information about the release of a signature key for the new stored software artifact to the signing unit (6) after storing the new software artifact in the software repository (2), and wherein the signing unit (6) is configured to sign the new stored software artifact using the released signature key. [3] System according to claim 1 or 2, wherein the system comprises a key storage unit (14) in which signature keys are stored, wherein the monitoring unit (4) is designed to send information about the authorization of a signature key for the new stored software artifact to the key storage unit (14), and wherein the signing unit (6) is designed to retrieve the authorized signature key for signing the new stored software artifact from the key storage unit (14). [4] System according to one of the preceding claims, wherein the system comprises a software artifact creation unit (10), wherein the software artifact creation unit (10) is configured to store the new software artifact in the software repository (2). [5] System according to claim 4, wherein the monitoring unit (4) is adapted to monitor the software artifact creation unit (10). [6] The system of claim 4 or 5, wherein the software artifact to be stored by the software artifact creation unit (10) is unsigned. [7] System according to one of the preceding claims, wherein the software repository (2) is configured to send a notification about the new stored software artifact to the monitoring unit (4) after storing the new stored software artifact, and / or wherein the monitoring unit (4) is configured to retrieve information about new stored software artifacts from the software repository (2). [8] System according to one of the preceding claims, wherein the monitoring unit (4) is designed to perform a security check of the software artifact before releasing the signature key. [9] The system of claim 8, wherein the security check comprises checking a checksum of the software artifact. [10] System according to one of the preceding claims, wherein the monitoring unit (4) is designed to determine a security level of the software artifact and to release a signature key corresponding to a security level of the software artifact. [11] System according to one of the preceding claims, wherein the monitoring unit (4) is designed to restrict use of the signature key to a predefined period of time. [12] System according to one of the preceding claims, wherein the monitoring unit (4) is designed to monitor the signing unit (6). [13] System according to claim 12, wherein the monitoring unit (4) is designed to monitor a use of signature keys by the signing unit (6) and, in case of unauthorized use of a signature key, to revoke the signature of a software artifact corresponding to the signature key. [14] A method for signing software artifacts, the method comprising the following steps: Monitoring (S1) a software repository (2), Saving (S2) a new software artifact in the software repository (2), Detecting (S3) the saving of the new stored software artifact or receiving information about the saving of the new stored software artifact, Sending (S4) an initiation signal for signing the new stored software artifact to a signing unit (6), and Signing (S5) the new stored software artifact based on the initiation signal. [15] Computer program product which causes the method according to claim 14 to be carried out on a program-controlled device.

Images