System for signing software artefacts
Patent Information
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-06-21
- Publication Date
- 2026-03-25
AI Technical Summary
Current systems for signing software artifacts, such as container images, lack assurance of input quality levels and cannot reliably verify the creation process, leading to potential security compromises, as they rely on unauthorized users and insecure authentication methods.
A system comprising a software repository, a monitoring unit, and a signing unit, where the monitoring unit initiates signing only after the software artifact is stored, ensuring authentication and quality checks are performed, and a key storage unit manages signature keys to prevent unauthorized signing.
This approach ensures that software artifacts are signed only after thorough monitoring and authentication, providing reliable assurance of their quality and integrity, reducing the risk of compromised or malicious images being introduced into the system.
Smart Images
Figure EP2024067508_26122024_PF_FP_ABST
Abstract
Description
[0001] 202309400 Foreign version 1 Description System for signing software artifacts 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 which causes the method for signing software artifacts to be carried out on a program-controlled device. Software artifacts, ie software containers which are created during a software development process, can be, for example, container images, etc. Software artifacts, such as container images, have the advantage that they contain a software application in the container, with the resources required for this, 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. 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, but also in applications in transport systems or vehicles. The IT systems underlying the application areas can be easily and flexibly adapted to new requirements by using container images, since these container images contain all the necessary data and information and are capable of running independently. In this way, the IT systems can be easily expanded and updated.202309400 Foreign Version 2 This flexibility provided by easily loadable container images, however, brings with it the threat that manipulated or malicious container images could be introduced into the corresponding system and compromise it. The origin, authenticity, and integrity of container images can be ensured using container signatures. These signatures are created at a specific point in the development process of a container image. In modern development processes, container images are created during the process of continuous integration and continuous delivery (CI / CD). 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 this is exactly the image with the created version.However, the signature generated during the development process does not contain any information about the quality of the container image. Systems using container images therefore currently cannot guarantee certain levels of input quality of the container images in addition to the origin, authenticity, and integrity. To date, container images have primarily been used unsigned, relying on the fact 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 that 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 any further verification of the container images. Furthermore, 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. Such solutions therefore do not allow any secure conclusions to be drawn about the container image creation process, the so-called software supply chain. This means that the signature service currently in use must trust the authorized users and cannot verify whether a software artifact or file to be signed is a legitimate software artifact.Container image was actually generated from the data pipeline provided for this purpose and certain security criteria were adhered to. Furthermore, the currently known methods use an authentication process when accessing the signature key, which in many cases is carried out with a password and possibly a user name. The authorizations (credentials) required for this purpose must be stored within a data pipeline for authentication at the signature service. Against this background, one object of the present invention is to provide a way to sign software artifacts in a simple manner, without the need for additional authentication, while at the same time allowing the security criteria of the software artifacts to be checked. This object is solved by the independent claims. Further developments of the invention can be found in the dependent claims.Accordingly, a system for signing software artifacts is proposed. 202309400 Foreign version 4 The system has a software repository for storing one or more software artifacts, a monitoring unit for monitoring the software repository, a software artifact creation unit configured to store a new software artifact in the software repository, and a signing unit for signing the software artifact. A software repository is understood to be a managed directory for storing software artifacts. The software repository contains the software artifacts, which may be, for example, container images. The software repository can therefore also be a container repository or a container registry.A container registry is a repository or collection of repositories in which container images can be stored and accessed. 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 execution. Such a software artifact can be, for example, a container image. The software artifact forms a self-contained unit that can generally function across platforms.The monitoring unit, also called supply chain monitoring, is designed to monitor the software artifact creation unit and, after saving a new software artifact in the software repository, to send an initiation signal to the signing unit to sign the newly stored software artifact. In contrast to previous systems, the software artifact is therefore not signed during the build process (202309400 Foreign Version 5), 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 separated from, or superordinate to, the creation process or the data pipeline used for it. The data pipeline therefore has no influence on the signing and has no knowledge of the signing unit.The monitoring unit is therefore preferably a higher-level unit, which in turn causes 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 the systems used previously, it is thus possible to implement monitoring of the software artifacts stored in the software repository using the monitoring unit and, based on this monitoring, to initiate the signing of newly stored software artifacts. The respective unit, for example, the monitoring unit or the 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 as a microprocessor or as a control unit on a server or the like. 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. 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 are provided separately from one another and that the monitoring unit is superior to the signing unit and can monitor and / or control it.According to one embodiment, 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 after the new software artifact has been stored in the software repository. Furthermore, the signing unit is configured to sign the newly stored software artifact using the released signature key. 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 signature key has been released by the monitoring unit. This introduces a control instance of the signing unit and the software repository.According to a further embodiment, the system has a key storage unit in which signature keys are stored, wherein the monitoring unit is designed to send information about the authorization of a signature key for the newly stored software artifact to the key storage unit, and wherein the signing unit is designed to retrieve the authorized signature key for signing the newly stored software artifact from the key storage unit. As already described above, the signature process is initiated by the monitoring unit. In this case, a checksum, e.g., a hash value, of the software artifact to be signed and all information required for identification can be transferred to the signing unit. 202309400 Foreign version 7 Furthermore, the monitoring unit can inform the signing unit of the key to be used for signing. In the key storage unit, which e.g.can be implemented by a key vault or a hardware security module, a plurality of signature keys can be stored. 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 can already exist, which only need to be released. Creating the required signature key is no longer necessary at this point. In one embodiment, the keys can be generated as soon as they are needed, so-called dynamically generated keys. These are then in turn controlled 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. According to a further embodiment, the system has a software artifact creation unit, wherein the software artifact creation unit is configured to store the newly stored software artifact in the software repository.202309400 Foreign Version 8 For example, a developer can start a build process to create a software artifact. It should be noted that, regardless of the grammatical gender of a particular term, this includes people with male, female, or other gender identities. The build process can be started on the software artifact creation 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 tests may be performed. The exact procedure for this is usually defined within the pipeline definition within the code repository.According to a further embodiment, the monitoring unit is designed to monitor the software artifact creation unit. This has the advantage that not only can the saving of a new software artifact be detected and a signing process initiated accordingly by the monitoring unit, but that the creation of the software artifact in the software artifact creation unit is also monitored. 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. In addition, the monitoring unit can thereby 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 checked for security.The environments should have a defined degree 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. 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. 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 manipulation or a quality defect is detected in the creation process chain, the monitoring unit can react accordingly and not initiate the signing of the software artifact and not release and authorize a signature key. 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 to identify a specific quality of the software artifact through the signature. In contrast to previous systems, the signing is only initiated by the monitoring unit 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.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 can passively be informed about new software artifacts by the software repository. 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 can, for example, include checking a checksum (e.g., checksum, hash value) of the software artifact.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. 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 creation process in the creation unit and its software artifacts. As described above, the monitoring unit can alternatively monitor the software repository and not be informed (so-called polling).In this case, the monitoring unit can actively perform checks on the creation unit and / or the software repository, either cyclically or based on other incoming events, and in particular, detect a new software artifact. The monitoring unit can assign the new software artifact to the corresponding creation process and is able to analyze 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, via a checksum (e.g., a hash value) of the generated software artifact. The software artifact itself and its configuration can also be monitored. In this way, vulnerabilities and misconfigurations can be identified, and the generated software artifacts can be evaluated.Within the monitoring unit, a policy can also be stored 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, 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 and the software artifact. This can be used to analyze the individual steps of the pipeline, as well as to check the security of the underlying infrastructure (e.g.,by comparing security groups, performing a vulnerability scan on the systems provided for the software artifact creation unit, ...). 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 checks 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, in that the monitoring unit authorizes 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. 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 signing 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. 202309400 Foreign Version 13 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, as an unauthorized signature can be revoked, marking the corresponding software artifact as no longer signed. If the software artifact is subsequently used by other processes, these processes can detect that the software artifact is no longer signed and thus refrain from further use, depending on the settings and specifications of the other processes. If the software repository cannot permanently store unsigned software artifacts, or if 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 registry for unsigned software artifacts, should be isolated and secured to prevent the use and transfer of unsigned software artifacts. 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.202309400 Foreign version 14 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 storage of the new software artifact or receiving information about the storage 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. Furthermore, a computer program product is proposed which causes the implementation of the method as explained above on a program-controlled device. A computer program product, such as a computer program means, can be used, for example, as a storage medium, such asMemory card, USB stick, CD-ROM, DVD, or also in the form of a downloadable file from a server in a network. This can occur, for example, in a wireless communications network by transmitting a corresponding file with the computer program product or the computer program means. The embodiments and features described for the proposed system apply accordingly to the proposed method. Further possible implementations of the invention also include combinations not explicitly mentioned of features or embodiments described previously or below with regard to the embodiments. The person skilled in the art will also add individual aspects as improvements or additions to the respective basic form of the invention.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 is 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. 2 shows a schematic diagram of the system according to Fig. 1 in a more detailed embodiment; Fig. 3 shows a schematic diagram of a creation process of a software artifact; and Fig. 4 shows a schematic flow diagram of a method for signing software artifacts. In the figures, identical or functionally equivalent elements have been provided with the same reference numerals unless otherwise stated. Fig. 1 shows a system 1 for the system for signing software artifacts.The system 1 has a software repository 2, a monitoring unit 4, and a signing unit 6. Although the individual units 2, 4, 6 are shown here as separate units, they can also be implemented in a single computing device. In this case too, however, the functionalities provided by the units 2, 4, 6 are separate, and the monitoring unit 4 always provides a higher-level unit with higher-level functionality. As can be seen in Fig. 1, the software repository 2, the monitoring unit 4, and the signing unit 6 are designed to communicate with one another. This communication can, for example, be wireless or wired, depending on the configuration. 202309400 Foreign Version 16 The monitoring unit 4 is designed 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. 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 newly stored software artifact. The initiation signal can also contain information about a signature key to be used. The signing unit 6 can then sign the newly stored software artifact using the signature key in response to the initiation signal (S5).In contrast to previous systems, the 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 location after the software artifact has been created and saved. In this way, system 1 can be integrated into any software artifact creation system (since no integration into the creation process is required; signing takes place after this). Second, system 1 is capable of performing a neutral review of the created and saved software artifacts, so that signing allows a neutral and secure statement about the quality and security of the software artifact. 202309400 Foreign Version 17 With reference to Fig. 2, the signing process and signing system 1 are described in more detail below.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 P1. In this embodiment, the monitoring unit 4 monitors, in addition to the software repository 2, also 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 created software artifact is monitored in its final state, but also the creation process, which increases the security and trustworthiness of the signing. Once the software artifact has been fully created, it is stored in the software repository 2 orloaded into it (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). As already described above, the monitoring unit 4 is designed to initiate the signing of the software artifact (S4) by sending a corresponding signal to the signing unit 6. In addition, the monitoring unit 4 can send a release 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).202309400 Foreign Version 18 Thus, the monitoring unit 4 can not only monitor the software repository 2 and initiate the signing of a software artifact, but the monitoring unit 4 is also capable of comprehensive monitoring of the entire system 1, or its units 10, 12, 2, 6, 14. In this way, precise and reliable monitoring of the generated software artifact and thus a trustworthy signing of the software artifact is possible. Manipulation of the software artifact can be detected through this comprehensive monitoring, and a signing can be rejected or revoked accordingly. As can be seen in Fig. 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. 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 sends its approval or rejection of the development configuration back 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 from these CA certificates can then in turn be used by the monitoring unit 4 to determine a security level of a 202309400 Foreign Version 19 software artifact and to select a corresponding signature key. If the development configuration corresponds to the approval rules 20, the software artifact is accepted and loaded into the software repository 2 (S2), as already described above. The higher-level monitoring and signing process can then be carried out by the monitoring unit 4 and the signing unit 6. Fig. 4 describes, by way of example, the method for signing a software artifact, as carried out by the system 1 of Figures 1 and 2. In a first step S1, the software repository 2 is first monitored.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 received by the monitoring unit 4. 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. As already explained above, this method enables higher-level monitoring and signing of software artifacts, which can be integrated into existing processes and systems and which also allows reliable and trustworthy signing of software artifacts.202309400 Foreign version 20 Although the present invention has been described using exemplary embodiments, it can be modified in many ways.
[0002] 202309400 Foreign version 21 List of reference symbols 1 System 2 Software repository 4 Monitoring unit 6 Signing unit 8 Developer 10 Software artifact creation unit 12 Software artifact creation process 14 Key storage unit 16 Software management unit 18 Approval unit 20 Approval rules P1-P8 Procedural steps S1-S5 Procedural steps
Claims
202309400 Foreign version 22 Patent 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), a signing unit (6) for signing a software artifact, and a software artifact creation unit (10) which is designed to store a new software artifact in the software repository (2), wherein the monitoring unit (4) is designed to monitor the software artifact creation unit (10) and, after storing the new software artifact in the software repository (2), to send an initiation signal for signing the new stored software artifact to the signing unit (6), and wherein the signing unit (6) is designed to Sign the 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 the new software artifact has been stored 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. The 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 configured 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 configured to automatically... 202309400 Foreign Version 23 rized 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 software artifact to be stored by the software artifact creation unit (10) is unsigned.
5. 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).
6. System according to one of the preceding claims, wherein the monitoring unit (4) is configured to perform a security check of the software artifact before releasing the signature key. 7.The system according to claim 8, wherein the security check comprises verifying a checksum of the software artifact.
8. The system according to any one of the preceding claims, wherein the monitoring unit (4) 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.
9. The system according to any one of the preceding claims, wherein the monitoring unit (4) is configured to restrict use of the signature key to a predefined period of time. 202309400 Foreign Version 24 10. The system according to one of the preceding claims, wherein the monitoring unit (4) is configured to monitor the signing unit (6).
11. The system according to claim 10, wherein the monitoring unit (4) is configured to monitor the use of signature keys by the signing unit (6) and, in the event of unauthorized use of a signature key, to revoke the signature of a software artifact corresponding to the signature key. 12.A method for signing software artifacts, the method comprising the following steps: monitoring (S1) a software repository (2) by a monitoring unit (4), storing (S2) a new software artifact in the software repository (2) by a software artifact creation unit (10) monitored by the monitoring unit, detecting (S3) the storing of the new stored software artifact by the monitoring unit or receiving, by the monitoring unit, information from the software repository about the storing of the new stored software artifact, sending (S4), by the monitoring unit, an initiation signal for signing the new stored software artifact to a signing unit (6), and signing (S5), by the signing unit, the new stored software artifact based on the initiation signal. 13.Computer program product which causes the method according to claim 12 to be carried out on a program-controlled device.