Method for securely running a software component

Abstract

Method for updating a software component, comprising the steps of: retrieving (A1) deployment information for a software component, wherein the deployment information (11) comprises information about program components of the software component and its runtime configuration; checking (A2) whether at least one program component has a weak spot and identifying the program component; determining (A3) a runtime restriction for the program component identified with a weak spot; inserting (S6) the runtime restriction information into the deployment information (11) for the software component; and performing (A4) a deployment of the software component according to the deployment information (11), wherein the software component is runtime restricted according to the runtime restriction information when performing the software component. The evaluation and the temporary adaptation of the runtime configuration information of the deployment configuration for the handling of weak spots in the software component to be updated makes the handling of the usability of zero-day exploits easier.

Description

TECHNICAL FIELD

[0001] The present invention relates to a method for securely running one or more software components, for example in a computer-controlled industrial automation system. The invention is particularly applicable in the context of a Continuous Integration / Continuous Delivery (CI / CD) pipeline. BACKGROUND

[0002] In many cases, software components are updated by deploying software containers. At the time of the update, weak spots can occur in the changed software components, which must be treated as security vulnerabilities.

[0003] Container images or container instances derived therefrom on a runtime environment and operating system or application components can contain such weak spots. In many cases, the weak spots are faulty or missing checks of the passed parameters in function calls. These weak spots can be exploited by attackers in such a way that, for example, specially prepared passed parameters are passed to socket functions or function calls in normal program code via exposed interfaces.

[0004] Attack techniques based thereon, such as remote code execution, SQL injection or privilege escalation, enable cyber attacks, which should be prevented.

[0005] If weak spots are identified, these can be published, for example in a publicly accessible database, for example on a manufacturer website or an aggregated database. At the same time, elimination processes are mostly introduced at the manufacturer of the software components involved, in such a way that, for example, parameter checks are adapted in the program code and a newer version of the software component is provided.

[0006] This mode of operation is part of the general software development process. However, the manufacturer of the respective software only maintains the software components supported by it. From a freely definable date, older versions are no longer maintained. Furthermore, it is often the case that in open source environments the responsibility is shared, so that on the one hand components such as libraries or programs are maintained by the manufacturer of the program. On the other hand, the updated components are then packaged and preconfigured by the distributor and run through the release process. Thereby, the quick elimination of critical weak spots is delayed.

[0007] There is a risk that software components containing weak spots are never updated or are not eliminated immediately. As long as the weak spots have not been eliminated, it is a question of zero-day vulnerabilities or zero-day exploits.

[0008] There is a desire for a solution that identifies known weak spots in software components on a system or container instance that have not yet been eliminated by a patch program and at least temporarily eliminates their exploitability until a fix is provided. SUMMARY

[0009] In this context, it is the task of the present invention to provide a secure operation of software, in particular in the case of software components to be updated.

[0010] Accordingly, a method for securely operating a software component is proposed, having the following steps:

[0011] retrieving deployment information for the software component, wherein the deployment information comprises information about program components of the software component and its runtime configuration;

[0012] checking whether at least one program component has a weak spot and identifying the program component;

[0013] determining a runtime restriction for the program component identified with the weak spot;

[0014] inserting the runtime restriction information into the deployment information for the software component; and

[0015] executing a deployment of the software component according to the deployment information, wherein the software component is runtime-restricted according to the runtime restriction information when executing the software component.

[0016] Evaluating and in particular temporarily adapting the runtime configuration information of the deployment configuration for the handling of weak spots in the software component to be updated makes it easier to handle the exploitability of zero-day exploits. This can be due to the changed runtime configuration for the program component identified as having a weak spot.

[0017] The respective software component is executed or run in a suitable processing or production environment.

[0018] The weak spot, for example, includes the possibility of passing unchecked parameters and / or undesired function calls by the software component. For example, adapting the deployment information when identifying the weak spot can enable a temporary revocation of privileges for the software component, so that the risk of damage is reduced.

[0019] In an embodiment, in this regard, the runtime restriction comprises an access right restriction and / or a restriction of outputting passed parameters or function calls to other software components.

[0020] Preferably, the method is executed automatically within the scope of a pipeline being built, such as a CI / CD pipeline. The method is particularly executed in a computer-implemented manner, for example, through a vulnerability scanning process. Vulnerability scanners, or simply scanners, are also mentioned.

[0021] In this implementation, a vulnerability scanner is integrated into the CI / CD pipeline. Instead of analyzing the software component images or software images themselves, the vulnerability scanner additionally evaluates deployment information. The software container images used are referenced in the deployment information (e.g., Kubernetes YAML files or Docker Compose files), which contain binaries and libraries or software libraries. The deployment information also includes descriptions of its runtime configuration, such as specific runtime limitations. The latter can be analyzed or scanned by the vulnerability scanner, thereby identifying one or more software components that are vulnerable.

[0022] In this implementation, the software component is implemented as an instance of a software container, and the associated software container image includes package information, binary files, libraries, and configuration data as part of the program.

[0023] In one implementation, deployment includes creating an adapted software container image for the software component based on deployment information supplemented with runtime limitations.

[0024] In this implementation, the adapted software container image is functionally validated in a secure processing environment prior to deployment. For example, a build pipeline generates the adapted software container image, and the corresponding software components are tested using a code repository.

[0025] Software components can be deployed in runtime environments such as Docker. Similarly, it is conceivable to orchestrate software containers, for example, using Kubernetes.

[0026] Preferably, the deployment information references one or more software container images.

[0027] In one implementation, the build pipeline prompts the updating of software components by inserting runtime constraint information in response to a merge request for the build pipeline.

[0028] For example, a vulnerability scanner generates a merge request, which is executed by a build pipeline initiated through a code repository.

[0029] In an implementation, verifying whether at least one program component has a vulnerability includes searching through the deployment information and / or scanning software container images, for example, using a vulnerability scanner.

[0030] In an implementation, the method further includes:

[0031] The deployment information is supplemented with vulnerability information, which is assigned to identified software components and / or program components identified as having vulnerabilities. This vulnerability information specifically includes information on the existence of vulnerabilities and / or the elimination of vulnerabilities through runtime constraints, and / or

[0032] Vulnerability information, which is assigned to the identified software components and / or program components that are identified as having vulnerabilities, is stored in the vulnerability database.

[0033] The vulnerability database can be retrieved during a software update, and its contents can be used to configure the vulnerability scanner.

[0034] In an implementation, the method further includes the steps of: searching for vulnerability information assigned to the software component and / or the identified program components in the deployment information for the software component; and

[0035] The software components are deployed based on the information about the weak points.

[0036] In the implementation, verifying whether at least one program component has a weakness further includes:

[0037] Information on weak points is stored as configuration data in the weak point database for use in the weak point scanning process.

[0038] Furthermore, a method for running a processing system configured to provide one or more software functions is proposed, wherein multiple interacting software components are executed in a runtime environment. In this method, one of the software components is updated according to a method as previously or described below.

[0039] The corresponding software components can be implemented as instances in a processing environment, particularly as software services or cloud services, and / or also as hardware technologies. When implemented in software technologies, the corresponding software functionality can be constructed as a computer program product, function, routine, part of program code, or executable object.

[0040] Furthermore, a computer program product is proposed, the computer program product including instructions that, when executed by a computer, cause the computer to perform the above-described method.

[0041] Computer program products, such as computer program components, can be provided or supplied, for example, as storage media, such as memory cards, USB sticks, CD-ROMs, DVDs, or as files downloadable from a server on a network. This can be done, for example, by transmitting corresponding files containing the computer program product or computer program component over a wireless communication network.

[0042] The measures proposed during software updates allow for the examination not only of the software components themselves, but also of the delivery solutions described in the detected vulnerability information, taking into account the application and its availability. This provides flexibility and efficiency in addressing vulnerabilities.

[0043] By leveraging the CI / CD pipeline and the tests defined within it, the functional capabilities of changes made to software components can be ensured.

[0044] Furthermore, the corresponding production environment can be tested using the configured adaptive deployments and defined vulnerability mitigation methods. The test results can then be fed back to the build pipeline.

[0045] Overall, software security has been improved.

[0046] Other possible implementations of the invention include combinations of features or embodiments not explicitly mentioned in the preceding or following descriptions of the embodiments. Those skilled in the art will also add unilateral aspects as improvements or supplements to the corresponding basic forms of the invention. Attached Figure Description

[0047] Other advantageous designs and aspects of the invention are the subject of the dependent claims and the embodiments described below. Furthermore, the invention will be explained in more detail with reference to the accompanying drawings and preferred embodiments.

[0048] Figure 1 A flowchart illustrating method steps of a first embodiment of a method for updating software components;

[0049] Figure 2 A block diagram illustrating the software and hardware components and processes used according to a second embodiment of the method for updating software components; and

[0050] Figure 3 A flowchart illustrating the method steps of a second embodiment of a method for updating software components is shown. Detailed Implementation

[0051] In the figures, unless otherwise specified, the same or functionally equivalent elements are equipped with the same reference numerals.

[0052] exist Figure 1The diagram illustrates a schematic flowchart for software updates. Typically, new software components, i.e., updated software, are deployed by compiling, testing, and merging software components or applications, with deployment information taken into account. According to existing technology, descriptions of weaknesses in software components are not included in the deployment information.

[0053] To ensure the secure operation of software components, for example in an automated network processing environment, deployment information for the software component is retrieved in the first step A1. Here, the deployment information contains information about the program components of the software component. If the software component exists as a software container image, the program components are, for example, package information, binary files, libraries, and / or configuration data. Configuration data, for example, determines the access permissions of the software component.

[0054] In subsequent step A2, at least one program component is examined to determine if it has an exploitable vulnerability, and the program component is identified if necessary. This examination can be derived from descriptions in the deployment information and / or from scan results, such as those performed by a vulnerability scanner, based on a search of software container images. Alternatively, the presence of the vulnerability may be read from a vulnerability database.

[0055] If no vulnerabilities are found based on the new software container image and / or vulnerability database, and critical vulnerability information cannot be derived from the deployment information, then test the software components, release them to the repository, and provide them to the production environment. Then proceed directly to step A4 (see below).

[0056] If a weakness is identified, runtime constraints are imposed on the program component with the identified weakness in step A3. For example, restrictions may be imposed on parameter output or passing from a software component to be updated to other software components, or to prevent unwanted function retrieval or interface release. Runtime constraints are described by runtime constraint information attached to the deployment information.

[0057] Finally, in step A4, the software component is deployed, taking into account deployment information that has been modified or adapted to the identified vulnerability. Therefore, during the execution of the software component, runtime limits are imposed on the software component based on runtime constraint information.

[0058] In this regard, it eliminates weaknesses or reduces their potential exploitation risks without waiting for a re-release of the software component. This approach is particularly effective in mitigating the damage risk of zero-day vulnerabilities or their exploitation.

[0059] The proposed solution has the advantage that, compared to common vulnerability scanners that only detect vulnerabilities in container images, deployment information associated with the image is examined within the CI / CD pipeline. This allows for the implementation of explicitly defined measures to (temporarily) limit vulnerabilities. Furthermore, if safeguards have already been implemented, such as the revocation of process privileges, vulnerabilities can be identified based on deployment information that may contain such information. The vulnerability information and / or runtime limitations attached to the deployment information also indicate whether the detected vulnerabilities can be fully exploited within the context of the software component.

[0060] Methods for securely running software components can, for example, enable the safe further operation of the processing environment after a software component update that exposes a zero-day exploit vulnerability. This operation is particularly understood as the execution of software components that interact with each other within a runtime environment.

[0061] The following is based on Figure 2 and 3 A second embodiment of a method for updating software components is explained. Here, Figure 1 The components involved in the method and their interactions are shown, and Figure 3 A communication diagram is shown.

[0062] The second embodiment is based on a CI / CD pipeline that includes a vulnerability scanner 2, a code repository 3, a build pipeline 4, a registry 5, a merge database 6, and a runtime environment 7. Figure 1 Other components of the processing system 1 are shown, which may be implemented as functional hardware or software services. The orchestrator 8 manages the T3 runtime environment 7 for instantiating the T4 software container 13. The vulnerability scanner 2 is communicatively coupled to the vulnerability database 10 and the cache memory 9. The vulnerability scanner 2 uses vulnerability information from the vulnerability database 10 (T5) and writes its scan results to or reads its scan results from the cache memory 9 (T7).

[0063] Code repository 3 manages and maintains TI deployment information 11. Container registry 5 provides software container images 12 (step T2). Merge requests entered by vulnerability scanner 2 are identified and stored in merge database 6, which are used and evaluated by build pipeline 4 (step T6).

[0064] When updating the software container image, i.e., when releasing a new version of the underlying software components, the aspects and steps described below can be performed.

[0065] Assume that the vulnerability scanner 2 has access to the objects to be searched or analyzed, in the considered example, software container images or container images, the package information contained therein, binary files, libraries, and configuration files. This can be done directly (step S2) or by retrieving the vulnerability database 10.

[0066] In step S1, the scanning process for the deployment configuration containing deployment information 11 may be part of the build pipeline 4, but alternatively may be or be an outsourced process performed periodically.

[0067] In step S2, the software container image 12 referenced in the deployment configuration or information 11 is searched in the registry 5 by the scanner 2, which is referenced in the deployment information 11 for the software component to be updated (step S2). During the scanning process, components or program parts running within the software container image are identified by accessing the package manager or by comparing binary signatures. The found components are compared with the vulnerability database 10, thereby identifying existing known vulnerabilities.

[0068] Since the same software container image, program components, or binary components can be referenced multiple times within a single deployment through different deployment configurations, the generated scan results are preferably stored intermediately in cache memory 9 (step T7). For example, for scanner 2, this is stored in a configuration file specifying when a rescan of the container image should be performed, or how old the list of vulnerable software components can be.

[0069] Within the CI / CD pipeline, images and binaries can be created through the translation process, or components generated elsewhere can be referenced. This information can be stored in a configuration file for Scanner 2, provided these are only referenced and used in other pipelines. Here, the configuration file can also specify which other pipeline the image will be generated in for the vulnerability scanning process or Scanner 2. Scanner 2 then evaluates this information during its corresponding runtime.

[0070] If a vulnerability cannot be eliminated by a software upgrade because the image is not built in the stored CI / CD pipeline, or because a patch has not yet been defined or the updated software component with the patch is not yet available, then the transitional solution defined in the vulnerability database 10 is reported back to the CI / CD pipeline by scanner 2. This occurs via merge request S3, which is recorded in merge database 6 by S4. As a transitional solution for the corresponding vulnerability, runtime constraints are set, such as restrictions on the privileges of software components. In particular, runtime constraints are implemented by assigning special Seccomp profiles or Linux capabilities defined to minimize the attack surface to revoke the process privileges of runtime users, and by assigning special installation options to the file system mounted for the instance. This is achieved by changing the deployment information updated in step S6. The build pipeline 4, started by the code repository in step S5, adapts the deployment information or deployment configuration accordingly.

[0071] Then, in step S7, pipeline 4 generates a container image or container image 12 of the software component to be updated, which is stored in registry 5 (S8). After testing the software component (S9), deployment (S10) can be performed.

[0072] Additionally, vulnerabilities can be prevented from being exploited by defining adapted mandatory access control profiles. Another possibility is to define corresponding configuration settings for software components introduced with the deployment, ensuring parameter validation for passed parameters and using regular expressions to identify and block corresponding structured calls.

[0073] Runtime constraints are imposed by initiating a merge request within pipeline 4 using the proposed runtime adaptation. Runtime adaptation or constraints in this case can be, for example, revoking specific permissions that are automatically proposed as adaptations in deployment configuration 11. The proposed changes can be verified by developers or, when using automatic merging, by means of (semi-)automatic unit and integration tests.

[0074] The runtime constraints to be enforced to prevent exploitation of vulnerabilities within the CI / CD pipeline are automatically generated merge requests that extend the defined runtime constraints to deployment information 11. Merge requests can be implemented automatically, semi-automatically (upon successful test traversal), or manually by the CI / CD pipeline operator. It is also conceivable that the merge request be implemented either manually, using the described semi-automatic method, or automatically, depending on the criticality of the detected vulnerability. The system's behavior is defined by the CI / CD pipeline manager, for example, in a configuration file.

[0075] Deployment parameters and configuration options introduced by Scanner 2 are marked accordingly during the merge for traceability and are referenced along with the mentioned vulnerabilities. References can be executed via the corresponding comments in the merge history.

[0076] In step S3, scanner 2 creates another merge request only when the vulnerability has been eliminated by introducing the corresponding patch and can no longer be detected. For this purpose, scanner 2 references in the outsourced database 6 which merge requests were executed for the deployment due to the detected vulnerability. The merge request ID is associated with the referenced vulnerability and deployment configuration. Within pipeline 4, on each subsequent scan, it is checked whether the referenced vulnerability is still identified and therefore the runtime constraints are still met. If this is no longer the case, the constraints can be lifted by generating a revert merge request.

[0077] As long as the build process 4 of image 12 occurs within its own CI / CD pipeline, it is conceivable that image 12 is translated using modified compilation operations (e.g., using Intel GET / Clang CFI to mitigate attacks such as ROP).

[0078] Furthermore, it is possible to temporarily alleviate new requirements or special hardware requirements on the underlying runtime platforms 7 and 8. In an orchestration cluster, it is conceivable that, within the scope of creating adapted deployment configurations, specific tags are assigned to the resulting images or deployment information, allowing the orchestrator 8 in the orchestrated container environment to automatically select the correct target platform 7 or to verify whether a newly introduced deployment can actually run on the platform.

[0079] If a temporary adaptation of privilege and configuration settings is applied via runtime restriction information included in the deployment information, the required functional tests are performed within build pipeline 4 (step S9). If these functional tests fail, the development team is notified. It is possible that, by definition by developers, specific identified weaknesses should not be eliminated through privilege adaptation (e.g., by referencing with CVE numbers or by time limits) in order to maintain the functionality of applications managed in the CI / CD pipeline.

[0080] To eliminate the possibility of exploiting vulnerabilities in the production environment, scanner 2 can compare the deployment configuration used in the production environment (step S11). The deployment configuration can be determined by scanner 2 either by querying orchestrator 8 or by directly accessing runtime environment 7. If deviations from the deployment are identified in the CI / CD pipeline, these deviations can also be reported to the CI / CD pipeline, for example, via corresponding warnings, events, or issues. Thus, the scanning process can be performed not only within the pipeline during build process 4 but also as a periodic scan.

[0081] Once the software component being mirrored or used in the pipeline no longer has a weak link, the configuration changes introduced by Scanner 2 can be automatically or manually canceled based on the configuration selected in the CI / CD pipeline, since the changes introduced by Scanner have already been referenced with the corresponding weak link.

[0082] By using deployment configuration data, vulnerabilities are automatically mitigated until patches for the affected software components become available.

[0083] Although the invention has been described with reference to embodiments, it can be modified in various ways. Although examples have been explained with reference to software containers, the method can also be used to update software components implemented in different ways. While a vulnerability scanner searches the software image, this also means that the vulnerability scanner retrieves vulnerability information about the software image from a vulnerability database.

Claims

1. A method for securely operating a software component, comprising the following steps: Retrieve (A1) deployment information for a software component, wherein the deployment information (11) includes information about the program components of the software component and its runtime configuration; Examine (A2) at least one program component for weaknesses and identify the program component; Determine (A3) runtime limitations for program components identified as having weaknesses; The runtime constraint information is inserted (S6) into the deployment information (11) for the software component; and The deployment of the software component is performed according to the deployment information (11) (A4), wherein the software component is subject to runtime restrictions according to the runtime restriction information during the execution of the software component.

2. The method according to claim 1, characterized in that, The software component is implemented as an instance of a software container (13), and the associated software container image (12) includes package information, binary files, libraries, and configuration data as program components.

3. The method according to claim 2, characterized in that, The deployment includes creating (S7, S8) adapted software container images (12) for the software components based on deployment information (11) supplemented with the runtime limitations.

4. The method according to claim 3, characterized in that, Before deployment (A4, S10), the adapted software container image (12) is functionally verified (S9) in a secure processing environment (3).

5. The method according to any one of claims 1-4, characterized in that, Deploy the software components (A4, S10) into the runtime environment (7, 8).

6. The method according to any one of claims 1-4, characterized in that, The deployment information (11) references one or more software container images (12).

7. The method according to any one of claims 1-4, characterized in that, The build pipeline prompts the software component to be updated by inserting runtime constraint information (S6) through a merge request (S3, S4) for the build pipeline (4).

8. The method according to any one of claims 1-4, characterized in that, Examining (A2) whether at least one program component has a weakness includes searching (S1) the deployment information (11) and / or scanning (S2) the software container image (12).

9. The method according to any one of claims 1-4, characterized in that, The runtime restrictions include access restrictions and / or restrictions on outputs or function calls that pass parameters to other software components.

10. The method according to any one of claims 1-4, further comprising: The deployment information (11) is supplemented (S3) with vulnerability information, which is assigned to the identified software components and / or program components that identify the vulnerabilities, wherein the vulnerability information includes the existence of vulnerabilities and / or the elimination of vulnerabilities through runtime constraints, and / or Vulnerability information assigned to the identified software components and / or program components that identify the vulnerabilities is stored in the vulnerability database (10).

11. The method according to any one of claims 1-4, further comprising: Search (S1) the deployment information for the software component for weaknesses assigned to the software component and / or the identified program components; and The software components are deployed based on the information about the weak points (S10, S11).

12. The method according to claim 10, characterized in that, Test (A2) whether at least one component of the procedure has a weakness, and also includes: The information on the weak links is stored as configuration data in the weak link database (10) for use in the weak link scanning process.

13. The method according to any one of claims 1-4, characterized in that, Vulnerabilities include the possibility of untested parameter passing by the software component and / or function calls made by the software component.

14. A method for running a processing system (1), said processing system being configured to provide one or more software functions, wherein a plurality of interacting software components are executed in a runtime environment (7), comprising: One of the software components is operated according to the method of any one of claims 1-13.

15. A computer program product comprising instructions that, when executed by one or more computers, cause the one or more computers to perform the method according to any one of claims 1-14.

Images