Verfahren zum sicheren Betrieb einer Softwarekomponente

Die vorliegende Erfindung betri f ft ein Verfahren zum sicheren Betreiben einer oder mehrerer Softwarekomponenten, beispielsweise in einem computergesteuerten industriellen Automatisierungssystem . Die Erfindung eignet sich insbesondere im Rahmen einer Continuous Integration/Continuous Delivery ( CI /CD) Pipeline .

In vielen Fällen erfolgt eine Aktualisierung von Softwarekomponenten über ein Deployment von Softwarecontainern . Es können bei der Aktualisierung in den veränderten Softwarekomponenten Schwachstellen auftreten, die als Sicherheitslücken behandelt werden müssen .

Container- Images bzw . auf einer Lauf zeitumgebung davon abgeleitete Container- Instanzen, aber auch Betriebssysteme oder Applikationskomponenten können solche Schwachstellen enthalten . In vielen Fällen handelt es sich bei Schwachstellen um fehlerhafte oder fehlende Überprüfungen von Übergabeparametern in Funktionsaufrufen . Diese können von einem Angrei fer ausgenutzt werden, indem z . B . speziell präparierte Übergabeparameter an Socket funktionen oder Funktionsaufrufe im normalen Programmcode durch exponierte Schnittstellen übergeben werden .

Darauf basierende Angri f fstechniken, wie Remote Code Execution, SQL- Inj ection oder das Erlangen privilegierter Berechtigungen ermöglichen Cyber-Security-Attacken die abzuwehren sind .

Werden Schwachstellen erkannt , können diese zum Beispiel in öf fentlich erreichbaren Datenbanken z . B . auf Herstellerwebsites oder aggregierten Datenbanken publi ziert werden . Gleichzeitig wird beim Hersteller der betrof fenen Softwarekomponente meist ein Behebungsprozess eingeleitet , indem z . B . im Programmcode die Parameterüberprüfung angepasst wird und eine neuere Version für die Softwarekomponente bereitgestellt wird .

Diese Vorgehensweise ist Teil des allgemeinen Software- Entwicklungsprozesses . Der Hersteller der j eweiligen Software pflegt j edoch lediglich die von ihm unterstützten Softwarekomponenten . Ältere Versionen werden ab einem vom Hersteller definierten Datum nicht mehr gepflegt . Zudem ist es oft so , dass im Open-Source-Umfeld die Verantwortlichkeiten geteilt sind, sodass einerseits Komponenten, wie Bibliotheken oder Programme , vom Hersteller der Programme gepflegt werden . Andererseits werden die aktualisierten Komponenten anschließend durch einen Distributor paketiert und vorkonfiguriert und durchlaufen einen Release-Prozess . Hierdurch wird das schnelle Beheben kritischer Schwachstellen verzögert .

Es besteht das Risiko , dass entweder nie die schwachstellenbehaftete Softwarekomponente aktualisiert wird oder es erfolgt keine unmittelbare Behebung . Solange die Schwachstelle noch nicht behoben ist , spricht man von Zero-Day-Lücken oder Zero-Day-Exploits .

Es besteht der Wunsch an einer Lösung, welche bekannte , noch nicht durch Patches behobene Schwachstellen in Softwarekomponenten auf einem System oder einer Container- Instanz identifi ziert und deren Ausnutzbarkeit zumindest übergangsweise bis zur Bereitstellung eines Fixes behebt .

Vor diesem Hintergrund besteht eine Aufgabe der vorliegenden Erfindung darin, einen sicheren Betrieb von Software zu schaf fen, insbesondere bei zu aktualisierenden Softwarekomponenten .

Demgemäß wird ein Verfahren zum sicheren Betrieb einer Softwarekomponente vorgeschlagen, mit den Schritten :

Abrufen einer Deploymentinf ormation für die Softwarekomponente , wobei die Deploymentinf ormation Informationen über Programmbestandteile der Softwarekomponente und deren Lauf- zeitkonf iguration umfasst ;

Prüfen, ob mindestens ein Programmbestandteil eine Schwachstelle aufweist und Identi fi zieren des Programmbestandteils ;

Bestimmen einer Lauf zeiteinschränkung für den mit einer Schwachstelle identi fi zierten Programmbestandteil ;

Einfügen einer Lauf zeiteinschränkungsinformation in die Deploymentinf ormation für die Softwarekomponente ; und Durchführen des Deployments der Softwarekomponente in Abhängigkeit von der Deploymentinf ormation, wobei die Softwarekomponente bei ihrer Aus führung der Lauf zeiteinschränkung gemäß der Lauf zeiteinschränkungsinformation unterliegt .

Die Auswertung und insbesondere temporäre Anpassung von Lauf- zeitkonf igurationsinf ormationen einer Deployment- Konfiguration zur Schwachstellenbehandlung in zu aktualisierenden Softwarekomponenten erleichtert die Handhabung von Ze- ro-Day-Exploit-Verwundbarkeiten . Dies kann durch eine veränderte Lauf zeitkonfiguration für einen als schachstellenbehaftet identi fi zierten Programmbestandteil sein .

Die Aus führung bzw . der Betrieb der j eweiligen Softwarekomponente erfolgt in einer geeigneten Verarbeitungs- oder Produktionsumgebung .

Eine Schwachstelle umfasst beispielsweise eine Übergabemöglichkeit von ungeprüften Parametern und/oder einen ungewünschten Funktionsaufruf durch die Softwarekomponente . Die Anpassung der Deploymentinf ormationen beim Erkennen einer Schwachstelle , ermöglicht beispielsweise einen vorübergehenden Privilegienent zug für die Softwarekomponente , sodass ein Schadrisiko reduziert wird .

In Aus führungs formen umfasst die Lauf zeiteinschränkung insofern eine Zugri f fsrechteeinschränkung und/oder die Beschränkung der Ausgabe von Übergabeparametern an andere Softwarekomponenten oder von Funktionsaufrufen . Das Verfahren wird vorzugsweise automatisch im Rahmen einer Build-Pipeline , welche beispielsweise Teil einer CI /CD- Pipeline ist , durchgeführt . Das Verfahren wird insbesondere computerimplementiert , etwa durch einen Schwachstellenscanprozess , durchgeführt . Man spricht auch von einem Schwachstellenscanner oder im Weiteren auch kurz : Scanner .

In Aus führungs formen wird ein Schwachstellenscanner in eine CI /CD-Pipeline eingebaut , wobei der Schwachstellenscanner nur nicht die Softwarekomponentenbilder bzw . Softwareimages selbst analysiert , sondern zusätzlich die Deploymentinf orma- tion auswertet . In der Deploymentinf ormation ( z . B . Kubernetes yaml-Dateien oder Docker-Compose-Dateien) sind die verwendeten Softwarecontainerimages ref erenziert , welche die Binärprogramme und Bibliotheken bzw . Libraries enthalten . Die Deploymentinf ormation enthält ferner Angaben zu deren Lauf- zeitkonf iguration, wie bestimmte Lauf zeiteinschränkungen . Letztere können durch den Schwachstellenscanner analysiert bzw . durchsucht werden, wodurch die von einer Schwachstelle betrof fene Sof twarekomponente/n identi fi ziert wird/werden kann/ können .

In Aus führungs formen ist die Softwarekomponente als Instanz eines Softwarecontainers implementiert , und ein zugehöriges Softwarecontainerbild umfasst Paketinf ormationen, Binärdateien, Bibliotheken und Konfigurationsdaten als Programmbestandteile .

In Aus führungs formen umfasst das Deployment die Erstellung eines angepassten Softwarecontainerbildes für die Softwarekomponente nach Maßgabe der um die Lauf zeiteinschränkung ergänzte Deploymentinf ormation .

In Aus führungs formen erfolgt dann vor dem Deployment eine Funktionsprüfung des angepassten Softwarecontainerbildes in einer gesicherten Abarbeitungsumgebung . Beispielsweise veranlasst eine Build-Pipeline die Erzeugung des angepassten Soft- warecontainerbildes , und führt mit Hil fe einer Code- Repository Tests an der entsprechenden Softwarekomponente durch .

Das Deployment der Softwarekomponente kann in einer Lauf zeitumgebung, wie beispielsweise Docker, erfolgen . Dabei ist ebenfalls denkbar, dass eine Orchestrierung, z . B . mit Hil fe von Kubernetes , von Softwarecontainern erfolgt .

Vorzugsweise referenziert die Deploymentinf ormation einen oder mehrere Softwarecontainerbilder .

In Aus führungs formen erfolgt das Einfügen einer Lauf zeiteinschränkungsinformation über einen Merge-Request für eine Build-Pipeline , welche die Aktualisierung der Softwarekomponente veranlasst .

Der Schwachstellenscanner erzeugt beispielsweise eine Merge- request , welcher von der durch die Code-Repository initiierte Build-Pipeline durchgeführt wird .

In Aus führungs formen umfasst das Prüfen, ob mindestens ein Programmbestandteil eine Schwachstelle aufweist , ein Durchsuchen der Deploymentinf ormation und/oder einen Scan des Softwarecontainerbildes , beispielsweise in der Art eines Schwachstellenscanners .

In Aus führungs formen umfasst das Verfahren ferner :

Ergänzen der Deploymentinf ormation um eine Schwachstelleninformation, welche der identi fi zierten Softwarekomponente und/oder dem mit der Schwachstelle identi fi zierten Programmbestandteil zugeordnet wird, wobei die Schwachstelleninformation insbesondere das Vorliegen einer Schwachstelle und/oder eine Behebung der Schwachstelle durch die Lauf zeiteinschränkung umfasst , und/oder

Speichern der Schwachstelleninformation, welche der identi fi zierten Softwarekomponente und/oder dem mit der Schwachstelle identi fi zierten Programmbestandteil zugeordnet ist , in einer Schwachstellendatenbank .

Die Schwachstellendatenbank kann bei erneuten Softwareaktualisierungen abgerufen werden und deren Inhalt für die Konfiguration des Schwachstellenscanners verwendet werden .

In Aus führungs formen umfasst das Verfahren auch die Schritte : Durchsuchen der Deploymentinf ormation für die Softwarekomponente nach einer Schwachstelleninformation, welche der Softwarekomponente und/oder dem identi fi zierten Programmbestandteil zugewiesen ist ; und

Durchführen des Deployments der Softwarekomponente in Abhängigkeit von der Schwachstelleninformation .

In Aus führungs formen umfasst das Prüfen, ob mindestens ein Programmbestandteil eine Schwachstelle aufweist , ferner :

Speichern der Schwachstelleninformation als Konfigurationsdaten in einer Schwachstellendatenbank für einen Schwachstellenscanprozess .

Es wird ferner Verfahren zum Betreiben eines Abarbeitungssystems , welches zur Bereitstellung einer oder mehrerer Softwarefunktionen eingerichtet ist , vorgeschlagen, wobei mehrere zusammenwirkende Softwarekomponenten in Lauf zeitumgebungen durchgeführt werden . Bei dem Verfahren erfolgt ein Aktualisieren einer der Softwarekomponenten gemäß einem Verfahren wie zuvor oder im Folgenden beschrieben ist .

Die j eweilige Softwarekomponente kann als Instanz in einer Verarbeitungsumgebung, insbesondere als Softwareservice oder Cloudservice und/oder auch hardwaretechnisch implementiert sein . Bei einer softwaretechnischen Implementierung kann die j eweilige Softwarefunktion als Computerprogrammprodukt , als eine Funktion, als eine Routine , als Teil eines Programmcodes oder als aus führbares Obj ekt ausgebildet sein . Weiterhin wird ein Computerprogrammprodukt vorgeschlagen, welches Befehle umfasst , die bei der Aus führung des Programms durch einen Computer diesen veranlassen, das vorstehend beschriebene Verfahren aus zuführen .

Ein Computerprogrammprodukt , wie z . B . ein Computerprogramm- Mittel , kann beispielsweise als Speichermedium, wie z . B . Speicherkarte , USB-Stick, CD-ROM, DVD, oder auch in Form einer herunterladbaren Datei von einem Server in einem Netzwerk bereitgestellt oder geliefert werden . Dies kann zum Beispiel in einem drahtlosen Kommunikationsnetzwerk durch die Übertragung einer entsprechenden Datei mit dem Computerprogrammprodukt oder dem Computerprogramm-Mittel erfolgen .

Die vorgeschlagenen Maßnahmen beim Aktualisieren von Software erlauben, dass nicht nur die verwendeten Softwarekomponenten selbst , sondern auch deren in der erfassten Schwachstelleninformation beschriebenen Übergangslösungen auf Anwendung und Ausnutzbarkeit überprüft werden . Daher wird an Flexibilität und Ef fi zient bei der Schwachstellenbehandlung gewonnen .

Die Funktions fähigkeit der durchgeführten Änderungen an der Softwarekomponente kann mit Hil fe der CI /CD-Pipeline und die in der Pipeline definierten Tests sichergestellt werden .

Es kann ferner die j eweilige Produktionsumgebung auf die Anwendung der definierten Schwachstellen-Workarounds durch das vorgesehene angepasste Deployment getestet werden . Das Testergebnis kann dann an die Build-Pipeline zurückgeliefert werden .

Insgesamt wird die Softwaresicherheit erhöht .

Weitere mögliche Implementierungen der Erfindung umfassen auch nicht expli zit genannte Kombinationen von zuvor oder im Folgenden bezüglich der Aus führungsbeispiele beschriebenen Merkmale oder Aus führungs formen . Dabei wird der Fachmann auch Einzelaspekte als Verbesserungen oder Ergänzungen zu der j eweiligen Grundform der Erfindung hinzufügen .

Weitere vorteilhafte Ausgestaltungen und Aspekte der Erfindung sind Gegenstand der Unteransprüche sowie der im Folgenden beschriebenen Aus führungsbeispiele der Erfindung . Im Weiteren wird die Erfindung anhand von bevorzugten Aus führungsformen unter Bezugnahme auf die beigelegten Figuren näher erläutert .

Fig . 1 zeigt ein Ablauf diagramm mit Verfahrensschritten für eine erste Aus führungs form eines Verfahrens zum Aktualisieren von Softwarekomponenten;

Fig . 2 zeigt ein Blockdiagramm für Soft- und Hardwarekomponenten und Prozesse , die gemäß einer zweiten Aus führungs form eines Verfahrens zum Aktualisieren von Softwarekomponenten verwendet werden; und

Fig . 3 zeigt ein Ablauf diagramm mit Verfahrensschritten für die zweite Aus führungs form des Verfahrens zum Aktualisieren von Softwarekomponenten .

In den Figuren sind gleiche oder funktionsgleiche Elemente mit denselben Bezugs zeichen versehen worden, sofern nichts anderes angegeben ist .

In Fig . 1 ist ein schematisches Ablauf diagramm für eine Softwareaktualisierung dargestellt . Üblicherweise erfolgt ein Deployment einer neuen Softwarekomponente , also die Aktualisierung der Software , durch ein Kompilieren, Testen und Morgen der Softwarekomponente bzw . Anwendung, wobei Deploymen- tinf ormationen berücksichtigt werden . Angaben über Schwachstellen der Softwarekomponente sind in der Deploymentinf orma- tion nach dem Stand der Technik nicht enthalten .

Um einen sicheren Betrieb einer Softwarekomponente , beispielsweise in einer Verarbeitungsumgebung eines Automatisie- rungsnet zwerks zu gewährleisten, wird in einem ersten Schritt Al eine Deploymentinf ormation für die Softwarekomponente abgerufen . Die Deploymentinf ormation enthält dabei Informationen über Programmbestandteile der Softwarekomponente . Falls die Softwarekomponente als Softwarecontainerbild vorliegt , sind die Programmbestandteile beispielsweise Paketinf ormatio- nen, Binärdateien, Bibliotheken und/oder Konfigurationsdaten . Die Konfigurationsdaten bestimmen zum Beispiel Zugri f fsrechte der Softwarekomponente .

Im Folgeschritt A2 wird geprüft , ob mindestens ein Programmbestandteil eine ausnutzbare Schwachstelle aufweist , und dieser Programmbestandteil wird gegebenenfalls identi fi ziert .

Die Prüfung kann anhand der Angaben in den Deploymentinf orma- tionen und/oder aus einem Scanergebnis aus einer Durchsuchung des Softwarecontainerbilds , etwas über einen Schwachstellenscanner, abgeleitet werden . Es ist auch denkbar, dass das Vorhandensein der Schwachstelle von einer Schwachstellendatenbank ausgelesen wird .

Falls weder auf Basis des neuen Softwarecontainerbildes und/oder einer Schwachstellendatenbank eine Schwachstelle gefunden wurde , noch kritische Schwachstelleninformationen aus der Deploymentinf ormation ableitbar sind, wird die Softwarekomponente getestet , der Release in das Repository durchgeführt und der Produktionsumgebung bereitgestellt . Es wird dann direkt der Schritt A4 (vgl . unten) durchgeführt .

Falls eine Schwachstelle gefunden wurde , wird im Schritt A3 eine Lauf zeiteinschränkung für den mit einer Schwachstelle identi fi zierten Programmbestandteil festgelegt . Es wird zum Beispiel eine Parameteraus oder -Übergabe der zu aktualisierenden Softwarekomponente an weitere Softwarekomponenten eingeschränkt , um ungewünschte Funktionsabrufe oder Schnittstellenfreigaben zu unterbinden . Die Lauf zeiteinschränkung wird durch eine Lauf zeiteinschränkungsinformation beschrieben, die der Deploymentinf ormation beigefügt wird . Schließlich erfolgt im Schritt A4 die Durchführung des Deployments der Softwarekomponente , wobei die geänderte bzw . an die erkannte Schwachstellensituation angepasste Deploymentinformation berücksichtigt wird . Die Softwarekomponente unterliegt dann bei ihrer Aus führung der Lauf zeiteinschränkung gemäß der Lauf zeiteinschränkungsinformation .

Die Schwachstelle wird insofern ausgeschaltet oder deren potentielles Ausnutzungsrisiko reduziert , ohne dass ein erneuter Softwarekomponentenrelease abgewartet werden muss . Das Verfahren mindert insbesondere das Schadrisiko von Zero-Day- Lücken oder Exploits .

Ein Vorteil der vorgeschlagenen Lösungen ist , dass im Vergleich zu üblichen Schwachstellenscannern, die nur Schwachstellen in Container- Images detektieren, innerhalb einer CI /CD-Pipeline die mit dem Image verbundenen Deploymentinf or- mationen überprüft werden . So lassen sich wohldefinierte Maßnahmen zum ( temporären) Einschränken einer Schwachstelle umsetzen . Ferner kann anhand der Deploymentinf ormationen, die Schwachstelleninformationen enthalten können, erkannt werden, wenn bereits Schutzmaßnahmen umgesetzt sind, beispielsweise dass Prozessprivilegien entzogen wurden . Die einer Deploymentinformation angehängte Schwachstelleninformation und/oder Lauf zeiteinschränkungsinformation kann auch angeben, ob eine detektierte Schwachstelle überhaupt im Kontext der Softwarekomponente ausnutzbar ist .

Das Verfahren zum sicheren Betrieb von Softwarekomponenten, kann beispielsweise nach einer Softwarekomponentenaktualisierung, die eine Zero-Day-Exploit-Schwachstelle of fenbart , einen sicheren Weiterbetreib der Verarbeitungsumgebung ermöglichen . Unter Betrieb wird insbesondere die Aus führung von miteinander zusammenwirkenden Softwarekomponenten in Lauf zeitumgebungen verstanden .

Im Weiteren wird ein zweites Aus führungsbeispiel für ein Verfahren zum Aktualisieren einer Softwarekomponente anhand der Fig. 2 und 3 erläutert. Dabei zeigt die Fig. 1 am Verfahren beteiligte Komponenten und deren Zusammenwirken, und die Fig.

3 ein Kommunikationsdiagramm.

Das zweite Ausführungsbeispiel basiert auf einer CI/CD- Pipeline mit einem Schwachstellenscanner 2, einer Code- Repository 3, einer Build-Pipeline 4, einer Registry 5, einer Merge-Datenbank 6 und einer Laufzeitumgebung 7. Die Fig. 1 zeigt weitere Komponenten des Abarbeitungssystems 1, die als funktionalisierte Hardware oder auch Softwareservices implementiert werden können. Ein Orchestrierer 8 verwaltet T3 die Laufzeitumgebung 7 zur Instantiierung T4 von Softwarecontainern 13. Der Schwachstellenscanner 2 ist kommunikativ mit einer Schwachstellendatenbank 10 und einem Cache 9 gekoppelt. Der Schwachstellenscanner 2 verwendet T5 die Schwachstelleninformationen aus der Schwachstellendatenbank 10 und schreibt und liest T7 seine Scanergebnisse in das bzw. von dem Cache 9.

Die Code-Repository 3 verwaltet TI Deploymentinf ormationen 11 und hält diese vor. Die Container-Registry 5 stellt jeweils Softwarecontainerbilder 12 bereit (Schritt T2) . In einer Merge-Datenbank 6 sind die von dem Schwachstellenscanner 2 eingetragene Merge-Requests identifiziert und abgelegt, welche von der Build-Pipeline 4 genutzt und ausgewertet T6 werden.

Bei der Aktualisierung eines Softwarecontainerbildes, also dem Release einer neuen Version der zugrunde liegenden Softwarekomponente, können die im weiteren beschriebenen Aspekte und Schritte durchgeführt werden.

Es wird angenommen, dass der Schwachstellenscanner 2 in der Lage ist, auf die zu durchsuchenden oder zu analysierenden Objekte, im betrachten Beispiel Softwarecontainerbilder bzw. Container-Images, darin enthaltene Paketinf ormationen, Binärdateien, Bibliotheken und Konfigurationsdateien) zuzugreifen. Dies kann direkt (Schritt S2) oder durch Abruf einer Schwachstellendatenbank 10 erfolgen. Im Schritt S I kann der Scanprozess der die Deploymentinf orma- tionen 11 enthaltene Deployment-Konf iguration Bestandteil der Build-Pipeline 4 sein, alternativ aber auch oder als ausgelagerter Prozess , der regelmäßig durchgeführt wird .

Die in der Deployment-Konf iguration bzw . Information 11 refe- renzierten Softwarecontainerbilder 12 werden im Schritt S2 vom Scanner 2 in den Registries 5 durchsucht , die in der Deploymeninf ormation 11 für die zu aktualisierende Softwarekomponente referenziert sind ( Schritt S2 ) . Im Scanvorgang werden die innerhalb des Softwarecontainerbildes betriebenen Komponenten bzw . Programmbestandteile durch Zugri f f auf den Paketmanager oder durch Abgleich von Binärsignaturen identifi ziert . Die gefundenen Komponenten werden mit einer Schwachstellendatenbank 10 abgeglichen wodurch vorhandene bekannte Schwachstellen identi fi ziert werden können .

Da die gleichen Softwarecontainerbilder, Programmbestandteile oder Binär-Komponenten mehrfach innerhalb eines Deployments durch unterschiedliche Deployment-Konf igurationen referenziert werden können, werden bevorzugt bereits erzeugte Scanergebnisse in dem Cache 9 zwischengespeichert ( Schritt T7 ) . Beispielsweise wird für den Scanner 2 in einer Konfigurationsdatei hinterlegt , zu welchem Zeitpunkt ein erneuter Scan des Container- Images durchgeführt werden soll oder wie alt die Liste der verwundbaren Softwarekomponenten sein darf .

In einer CI /CD-Pipeline können Images und Binärdateien durch Übersetzungsvorgänge erstellt werden oder an anderer Stelle erzeugte Komponenten können referenziert werden . Sofern diese lediglich referenziert werden und in anderen Pipelines verwendet werden, kann diese Information in einer Konfigurationsdatei für den Scanner 2 hinterlegt werden . Dabei kann in der Konfigurationsdatei für den Schwachstellenscanprozess bzw . den Scanner 2 auch abgelegt werden, in welcher anderen Pipeline ein Image erzeugt wird . Der Scanner 2 wertet diese Information dann zur j eweiligen Lauf zeit aus . Kann eine Schwachstelle nicht durch ein Software-Update behoben werden, da das Image z . B . nicht in der hinterlegten CI /CD-Pipeline gebaut wird oder da noch kein Patch definiert oder eine den Patch aufweisende aktualisierte Softwarekomponente verfügbar ist , werden die in der Schwachstellendatenbank 10 definierten Übergangslösungen durch den Scanner 2 an die CI /CD-Pipeline zurückgemeldet . Dies geschieht durch eine Merge-Request S3 , der in der Merge-Datenbank 6 dokumentiert wird S4 . Als Übergangslösung für die j eweilige Schwachstelle ist eine Lauf zeiteinschränkung vorgesehen, beispielsweise eine Einschränkung von Privilegien der Softwarekomponente . Lauf zeitrestriktionen sind insbesondere das Entziehen von Prozessprivilegien des Lauf zeitnutzers mit Hil fe der Zuweisung spezieller, zur Minimierung der Angri f fs fläche definierter Seccomp-Prof ile oder Linux-Capabilities sowie die Zuweisung spezieller Einhängeoptionen für die Instanz eingehängten Dateisysteme . Dies wird durch eine Änderung der Deploymentin- formationen erzielt , die im Schritt S 6 aktualisiert werden . Die im Schritt S5 durch die Code-Repository gestartete Build- Pipeline 4 passt die Deploymentinf ormation bzw . Deployment- Konf iguration entsprechend an .

Die Build-Pipeline 4 erzeugt dann im Schritt S7 das Container- Image bzw . das Containerbild 12 der zu aktualisierenden Softwarekomponente , welches von der Registry 5 gespeichert wird S 8 . Nach dem Testen S 9 des der Softwarekomponente kann ein Deployment durchgeführt werden S 10 .

Zusätzlich kann das Ausnutzen einer Schwachstelle durch die Definition eines angepassten Mandatory-Access-Control-Prof ils verhindert werden . Eine weitere Möglichkeit ist die Definition entsprechender Konfigurationseinstellungen für die mit dem Deployment eingebrachte Softwarekomponente derart , dass Parameterüberprüfungen für Übergabeparametern sichergestellt werden und entsprechend strukturierte Aufrufe mit Hil fe von regulären Ausdrücken erkannt und blockiert werden . Die Lauf zeiteinschränkung erfolgt , indem ein Merge-Request innerhalb der Pipeline 4 mit den vorgeschlagenen Lauf zeitanpassungen eröf fnet wird . Lauf zeitanpassungen bzw . Lauf zeiteinschränkungen können hierbei z . B . das Entziehen bestimmter Rechte sein, die automatisch als Anpassung in der Deployment- Konf iguration 11 vorgeschlagen werden . Die vorgeschlagenen Änderungen können vom Entwickler geprüft werden oder bei der Verwendung automatischer Merges mit Hil fe (halb- ) automatischer Unit- und Integrationstests geprüft werden .

Der automatisch generierte Merge-Request , welcher die durchzuführenden Lauf zeitrestriktionen zum Verhindern der Ausnutzung der Schwachstelle in der eigenen CI /CD-Pipeline fordert , erweitert die Deployment- Information 11 um die definierten Lauf zeitrestriktionen . Der Merge-Request kann entweder automatisch, halbautomatisch (beim erfolgreichen Durchlaufen der Tests ) oder manuell durch die Betreiber der CI /CD-Pipeline umgesetzt werden . Es ist auch denkbar, dass diese abhängig von der Kritikalität der detektierten Schwachstelle entweder manuell , mit dem beschrieben halbautomatischen Verfahren oder automatisch umgesetzt wird . Das Verhalten des Systems wird vom Verantwortlichen der CI /CD-Pipeline in einer z . B . in einer Konfigurationsdatei definiert .

Die über den Scanner 2 eingebrachten Deployment-Parameter und Konfigurationsoptionen werden bei einem Merge zur Nachvollziehbarkeit entsprechend markiert und mit der genannten Schwachstelle ref erenziert . Die Referenz kann durch entsprechende Kommentare in der Merge-History durchgeführt werden .

Ein weiterer Merge-Request wird vom Scanner 2 erst im Schritt S3 erstellt , wenn die Schwachstelle durch Einbringung eines entsprechenden Patches behoben ist und nicht mehr detektiert werden kann . Hierzu wird für den Scanner 2 in einer ausgelagerten Datenbank 6 ref erenziert , welche Merge-Requests aufgrund einer detektierten Schwachstelle für ein Deployment durchgeführt wurden . Die ID des Merge-Requests mit den hierdurch ref erenzierten Schwachstellen und der Deployment- Konfiguration verknüpft. Innerhalb der Pipeline 4 wird bei jedem nachfolgenden Scan überprüft, ob die ref erenzierte Schwachstelle noch erkannt wird und somit die Bedingungen für die Laufzeiteinschränkungen noch erfüllt sind. Ist dies nicht mehr der Fall, können die Einschränkungen durch Erzeugung eines Undo-Merge-Requests rückgängig gemacht werden.

Sofern der Build-Prozess 4 des Images 12 innerhalb der eigenen CI/CD-Pipeline stattfindet, ist denkbar, dass das Image 12 mit veränderten Compile-Operationen (z.B. Verwenden von Intel GET / Clang CFI, um z.B. ROP-Angriffe zu mitigieren) übersetzt wird.

Des Weiteren ist es möglich, dass eine temporäre Mitigation neue Anforderungen an die darunterliegende Laufzeit-Plattform 7, 8 hat oder die spezielle Hardware-Anforderungen erforderlich sind. In einem orchestrierenden Cluster ist denkbar, dass im Rahmen der Erstellung einer angepassten Deployment- Konf iguration den erzeugten Images oder Deploymentinf ormatio- nen spezielle Labels zugewiesen werden, sodass in einem orchestrierten Container-Umfeld der Orchestrator 8 automatisch die richtige Zielplattform 7 auswählen kann bzw. überprüfen kann, ob das neu eingebrachte Deployment auf der Plattform überhaupt lauf fähig ist.

Sind die temporären Anpassungen der Privilegien und Konfigurationseinstellungen durch die in den Deploymentinf ormationen enthaltenen Laufzeiteinschränkungsinformation angewendet, werden innerhalb der Build-Pipeline 4 erforderliche Funktionstests (Schritt S9) durchgeführt. Schlagen diese fehl, wird das Entwicklerteam informiert. Es ist möglich, dass durch den Entwickler händisch definiert wird, dass zur Aufrechterhaltung der Funktionsfähigkeit der in der CI/CD-Pipeline verwalteten Applikation auch bestimmte, identifizierte Schwachstellen (z.B. durch Ref erenzierung mit CVE-Nummern oder durch Zeitbeschränkung) nicht durch Privilegienanpassung behoben werden sollen. Um aus zuschließen, dass die Ausnutzung von Schwachstellen auf der Produktionsumgebung erfolgen, können vom Scanner 2 die verwendeten Deployment-Konf igurationen auf der Produktionsumgebung abgeglichen werden ( Schritt S i l ) . Die Deployment- Konf igurationen können vom Scanner 2 entweder beim Orchest- rierer 8 abgefragt werden oder durch direkten Zugri f f auf die Lauf zeitumgebung 7 ermittelt werden . Werden Abweichungen zum Deployment in der CI /CD-Pipeline festgestellt , können ebenfalls Abweichungen z . B . über entsprechende Warnungen bzw . Incidents oder I ssues an die CI /CD-Pipeline gemeldet werden . Auch dann kann der Scan-Vorgang sowohl im Rahmen des Build- Prozesses 4 innerhalb der Pipeline ausgeführt werden oder als periodischer Scan .

Sobald ein Image bzw . die in der Pipeline verwendete Softwarekomponente keine Schwachstelle mehr aufweist , können die vom Scanner 2 eingebrachten Konfigurationsänderungen in Abhängigkeit von der in der CI /CD-Pipeline gewählten Konfiguration automatisch oder manuell rückgängig gemacht werden, denn die vom Scanner eingebrachten Änderungen wurden mit den entsprechenden Schwachstellen ref erenziert .

Durch die Nutzung von Deployment-Konf igurationsdaten wird eine Schwachstelle automatisch neutralisiert , bis ein Patch für die betrof fene Softwarekomponente verfügbar ist .

Obwohl die vorliegende Erfindung anhand von Aus führungsbeispielen beschrieben wurde , ist sie viel fältig modi fi zierbar . Obwohl die Beispiele anhand von Softwarecontainern erläutert wurden, können auch anders implementierte Softwarekomponenten gemäß dem Verfahren aktualisiert werden . Obwohl formuliert ist , dass Schwachstellenscanner Softwareimages durchsuchen, ist damit auch gemeint , dass der Schwachstellenscanner Schwachstelleninformationen zu dem Softwareimage in einer Schwachstellendatenbank abruft .