DE102020118479A1

DE102020118479A1 - Verfahren zum Ermöglichen einer automatischen Evaluierung eines aktuellen Software-Sicherheitsstatus und Datenverarbeitungseinrichtung

Info

Publication number: DE102020118479A1
Application number: DE102020118479.4A
Authority: DE
Inventors: Albrecht Neff; Markus Hosch; Daniel Dodu; Nikola Radakovic; Luiz Cordeiro; Florian Bogenberger
Original assignee: Bayerische Motoren Werke AG
Current assignee: Bayerische Motoren Werke AG
Priority date: 2020-07-14
Filing date: 2020-07-14
Publication date: 2022-01-20

Abstract

Die Erfindung betrifft ein Verfahren zum Ermöglichen einer Evaluierung eines aktuellen Software-Sicherheitsstatus sowie eine entsprechende Datenverarbeitungseinrichtung. Dazu wird für ein Softwaresystem ein gerichteter Graph erzeugt, der Abhängigkeiten zwischen den Knoten zugeordneten Softwareteilen repräsentiert. In jedem Knoten gibt dabei ein Sicherheitsattribut den aktuellen Sicherheitsstatus des jeweiligen zugeordneten Softwareteils an. Für die Blätter des Graphen wird deren jeweiligen Sicherheitsattribut vorgegeben. Zudem werden Regeln vorgegeben, die angeben, wie für die übrigen Knoten zum Bestimmen von deren jeweiligem Sicherheitsattribut die Sicherheitsattribute der jeweils hierarchisch untergeordneten Knoten entlang einer Struktur des Graphen miteinander zu kombinieren sind.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Ermöglichen einer automatischen Evaluierung eines aktuellen Software-Sicherheitsstatus und eine entsprechende Datenverarbeitungseinrichtung.
Heutzutage wird in vielen - auch sicherheitskritischen - Bereichen komplexe Software eingesetzt, beispielsweise zur Steuerung oder Überwachung von Geräten und Prozessen. Je nach Anwendungsfall kann es dabei von besonderer Bedeutung sein, dass die funktionale Sicherheit automatisierter oder teilautomatisierter Steuerungen und Prozesse sichergestellt ist. Einen solchen Anwendungsfall stellt die autonome Steuerung von Kraftfahrzeugen dar. Hierzu gibt es bereits normative Vorgaben, beispielsweise die ISO-Norm ISO 26262 bezüglich der funktionalen Sicherheit für sicherheitsrelevante elektrische und elektronische Systeme in Straßen- beziehungsweise Kraftfahrzeugen. Darin sind als Sicherheits- oder Risikoklassifizierungsschema verschiedene ASIL (englisch: Automotive Safety Integrity Level) definiert.
Mit der heutzutage immer weiter zunehmenden Komplexität der zur Steuerung oder zum Betrieb von Kraftfahrzeugen eingesetzten Software gestaltet sich die Sicherstellung der Sicherheit dieser Software, der entsprechenden Funktionen des Kraftfahrzeugs beziehungsweise des Kraftfahrzeugs insgesamt zunehmend aufwendiger und fehleranfälliger. Heutzutage wird der Sicherheitszustand oder Sicherheitsstatus eines komplexen Softwareprojekts sowie von dessen Komponenten oder Modulen oftmals manuell verwaltet, beispielsweise in einer händisch gepflegten Tabelle. Problematisch ist dabei, dass dies fehleranfällig und nicht ohne Weiteres verifizierbar ist und nicht mit der Größe oder Komplexität des jeweiligen Projekts skaliert, also bei großen Softwareprojekten zu einem überproportionalen und nicht ohne Weiteres handhabbaren Aufwand führen kann. Ebenso ist es mit einem derartigen Ansatz kaum praktikabel, häufige Aktualisierungen des Sicherheitszustands durchzuführen. Zudem können konzeptionelle Änderungen auf einem fundamentalen Niveau des jeweiligen Projekts ebenfalls zu einem kaum handhabbaren Aufwand in der Verwaltung oder Aktualisierung sämtlicher relevanter Sicherheitsstatus oder Sicherheitszustände führen.
Ein Beispiel, wie heutzutage Software im Fahrzeugbereich gehandhabt werden kann, ist in der DE 10 2017 204 212 A1 beschrieben. Dort ist ein Verfahren zum Verwalten von Applikationen für Fahrzeuge mittels eines Back-Ends offenbar. Darin werden Ressourcenangebote der Fahrzeuge sowie Anforderungsprofile der Applikationen auf dem Back-End hinterlegt. Dort wird dann ein erster Abgleich der Ressourcenangebote eines identifizierten Fahrzeugs gegen die Anforderungsprofile durchgeführt. Eine anhand dieses ersten Abgleichs ausgewählte Applikation wird dann vom Back-End an das Fahrzeug übertragen. Ressourcen können dabei beispielsweise auch benötigte Kommunikationskanäle mit bestimmten Eigenschaften, etwa hinsichtlich einer Bandbreite oder eines ASIL, umfassen. Können entsprechende Anforderungen nicht befriedigt werden, so kann die betreffende Applikation nicht geladen oder gestartet werden. Dies kann zwar letztlich die Sicherheit beim Ausführen entsprechender Applikationen in dem jeweiligen Fahrzeug steigern, jedoch nicht die Sicherheit der Applikationen selbst sicherstellen und muss sich daher auf eine zuverlässige und korrekte Entwicklung und Implementierung der Applikationen verlassen.
Als ein weiterer Ansatz zur Verbesserung der Sicherheit ist in der US 2020 / 0 065 234 A1 ein Verfahren zum Auswählen eines minimalen Satzes von Testfällen zum Abdecken der funktionalen Sicherheit beschrieben. Dabei wird für vorgegebene Fehlerfälle überprüft, ob diese durch vorgegebene Testfälle abgedeckt sind, also detektiert werden, und es wird eine entsprechende Bewertung vergeben.
Aufgabe der vorliegenden Erfindung ist es, die Softwaresicherheit und eine entsprechende Überprüfbarkeit insbesondere im Bereich der Fahrzeugtechnik zu verbessern. Diese Aufgabe wird erfindungsgemäß durch die Gegenstände der unabhängigen Patentansprüche gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen der vorliegenden Erfindung sind in den abhängigen Patentansprüchen, in der Beschreibung und der Zeichnung angegeben.
Das erfindungsgemäße Verfahren dient zum Ermöglichen einer, insbesondere automatischen oder teilautomatischen, Evaluierung beziehungsweise Verwaltung eines aktuellen Software-Sicherheitsstatus oder Sicherheitszustands. In dem Verfahren wird für ein vorgegebenes Softwaresystem, das mehrere Softwareteile umfasst, insbesondere automatisch oder teilautomatisch, ein gerichteter Graph oder Baum erzeugt, dessen Struktur Abhängigkeiten oder Relationen zwischen den Softwareteilen repräsentiert beziehungsweise angibt oder widerspiegelt. Ein Softwareteil in diesem Sinne kann beispielsweise eine in Software implementierte Funktion oder Routine, eine Gruppe solcher Funktionen oder Routinen, eine Bibliothek, eine Quellcodedatei, eine Gruppe von Quellcodedateien oder dergleichen auf Code- oder Implementierungsebene sein oder umfassen. Die Softwareteile werden im Folgenden auch als Softwaremodule bezeichnet. Dass der Graph gerichtet ist, bedeutet hier, dass Abhängigkeiten entlang der Struktur des Graphen, also etwa entlang einer Kante oder zwischen zwei durch eine Kante miteinander verbundenen Knoten des Graphen, nur in eine Richtung gegeben sind. Sind beispielsweise ein Knoten A und ein Knoten B durch eine Kante miteinander verbunden und ist Knoten B abhängig von Knoten A, so kann dann Knoten nicht von Knoten B abhängig sein. Derartige Abhängigkeiten können hier Softwareabhängigkeiten sein, also etwa durch einen Aufruf eines anderen Softwareteils oder einer in einem anderen Softwareteil enthaltenen oder implementierten Funktion, durch eine Inkludierung eines anderen Softwareteils oder dergleichen gegeben sein. Jeder Softwareteil wird dabei einem Knoten des Graphen zugeordnet.
Für einen bestimmten Knoten oder einen diesem zugeordneten Softwareteil können dessen Kinder beziehungsweise die diesen zugeordneten Softwareteile von diesem bestimmten Knoten oder dessen Softwareteil abhängig sein oder beispielsweise Untereinheiten oder Teile bilden oder umfassen. Ein Softwareteil eines ersten Knotens kann also beispielsweise eine bestimmte erste Funktion implementieren oder repräsentieren. Von diesem ersten Knoten abhängigen zweiten Knoten, also diesem hierarchisch untergeordneten Knoten oder Kindern, können dann Softwareteile zugeordnet sein, die Teilfunktionen der ersten Funktion implementieren oder repräsentieren. Der Wurzelknoten des Graphen beziehungsweise der dem Wurzelknoten zugeordnete Softwareteil kann dann beispielsweise eine jeweilige gesamte oder ausführbare Software, welche zumindest die übrigen Softwareteile umfasst oder referenziert - auch bezeichnet als build target - sein oder repräsentieren.
Die Knoten des Graphen weisen jeweils wenigstens ein Datenfeld für wenigstens ein jeweiliges Sicherheitsattribut auf. Ein solches Sicherheitsattribut beziehungsweise dessen Wert eines Knotens gibt dabei den aktuellen Sicherheitsstatus - beispielsweise hinsichtlich einer funktionalen Sicherheit, einer Fehlerfreiheit, einer Betriebs- oder Anwendungssicherheit oder dergleichen - wenigstens eines dem jeweiligen Knoten zugeordneten Softwareteils an. Dabei können einem Knoten jeweils genau ein Softwareteil oder mehrere Softwareteile zugeordnet sein. Ein Sicherheitsattribut kann jeweils den Sicherheitsstatus genau eines Softwareteils oder beispielsweise den Sicherheitsstatus mehrerer oder aller der dem jeweiligen Knoten zugeordneten Softwareteile angeben. Die Sicherheitsattribute beziehungsweise die Datenfelder können beispielsweise in dem Graphen gespeichert, also Teil des Graphen sein. Ebenso kann hierfür aber beispielsweise eine weitere Datenstruktur verwendet werden.
Weiter wird bei dem Verfahren für die Blätter des Graphen, also für dessen Blattknoten oder äußere Knoten oder Endknoten, deren jeweiliges Sicherheitsattribut vorgegeben. Mit anderen Worten werden also die Sicherheitsattribute der Blätter beziehungsweise deren Werte festgelegt oder auf einen jeweiligen vorgegebenen Wert gesetzt. Dies kann beispielsweise manuell oder durch einen entsprechenden Input von außen erfolgen. Sofern für ein Blatt des Graphen dessen Sicherheitsattribut nicht manuell gesetzt wird oder worden ist, kann für diesen stattdessen beispielsweise automatisch ein vorgegebener Standardwert gesetzt werden. Ein solcher Standardwert kann dabei bevorzugt ein minimales oder schwächstes Sicherheitsattribut sein, also einen minimalen oder schwächsten, also unsichersten Sicherheitszustand angeben. Damit wird letztlich eine konservative, besonders sichere Sicherheitsbewertung sichergestellt.
Die von den Blättern verschiedenen Knoten, also innere Knoten und Wurzelknoten des Graphen werden hier als übrige Knoten bezeichnet.
Weiter werden bei dem Verfahren Regeln vorgegeben, die angeben, wie für die übrigen Knoten zum Bestimmen von deren jeweiligem Sicherheitsattribut oder deren jeweiligen Sicherheitsattributen die Sicherheitsattribute der jeweils hierarchisch untergeordneten Knoten entlang der Struktur des Graphen miteinander zu kombinieren sind. Die Regeln können beispielsweise für jeden Knoten vorgegeben sein, der durch eine Kante des Graphen direkt mit wenigstens einem hierarchisch untergeordneten Knoten verbunden ist. Ebenso können die oder einige der Regeln beispielsweise für entsprechende Kanten vorgegeben sein. Mit anderen Worten können die Regeln also jeweils einem Knoten oder einer Kante des Graphen zugeordnet sein, wobei ein jeweiliges, in den entsprechenden Datenfeldern der - insbesondere entlang der jeweiligen Kante hierarchisch untergeordneten - Knoten angegebenes Sicherheitsattribut, insbesondere ein standardisiertes Sicherheitslevel, wie etwa ein ASIL, als Input für die Regeln dient. Mit anderen Worten können die Kanten und/oder die Knoten des Graphen entsprechend mit den Regeln, das heißt letztlich algorithmischen Vorgaben, bezüglich der Kombination oder Verarbeitung von Sicherheitsattributen annotiert sein.
Die Regeln werden dabei insbesondere in maschinenlesbarer Form bereitgestellt, können also in einer vorgegebenen Form und/oder Struktur formalisiert sein. Beispielsweise können die Regeln in einer vorgegebenen Programmiersprache formuliert oder implementiert sein. Eine solche Sprache kann also sicherheitsrelevante Relationen, Abhängigkeiten oder Beziehungen zwischen verschiedenen Sicherheitsattributen formalisiert beschreiben. Bevorzugt kann hier eine Sprache verwendet werden, die Mechanismen zum Definieren oder formalisierten Ausdrücken von Dekompositionen von Sicherheitsattributen, also insbesondere ASIL-Dekompositionen, und/oder technischen Bedingungen oder Annahmen wie beispielsweise Störungsfreiheit (englisch: freedom from interference) zwischen zwei Komponenten, Funktionen oder Softwareteilen, MPU-Aktivierung, Compiler-Qualifizierung, oder dergleichen mehr umfasst.
Basierend auf dem - zumindest mit den Sicherheitsattributen der Blätter annotierten beziehungsweise diese umfassenden - Graphen und den vorgegebenen Regeln kann dann also eine Bestimmung, also eine Berechnung oder Aktualisierung, der Sicherheitsattribute für die übrigen Knoten ausgehend von den Blättern beziehungsweise deren vorgegebenen Sicherheitsattributen entlang der Struktur des Graphen erfolgen. Dies kann insbesondere automatisch erfolgen, etwa durch einen vorgegebenen Algorithmus. Es können hier also beispielsweise immer die Sicherheitsattribute aller Knoten einer Gruppe von Geschwisterknoten zum Sicherheitsattribut von deren hierarchisch übergeordnetem Elternknoten kombiniert werden. Dies kann entsprechend bis hin zum Wurzelknoten des Graphen fortgesetzt werden.
Die Regeln können also automatisch ausgewertet oder angewendet werden, beispielsweise durch den entsprechenden vorgegebenen Algorithmus. Einem solchen Algorithmus können die Regeln als Input gegeben werden oder der Algorithmus kann eine Implementierung der Regeln sein oder umfassen. Zumindest können aber die vorgegebenen Sicherheitsattribute zumindest der Blätter des Graphen einen Input, also Eingangsdaten für den Algorithmus bilden. Besonders bevorzugt können die Sicherheitsattribute der Blätter bezüglich des Algorithmus fest, also konstant sein, das heißt durch den Algorithmus nicht verändert werden. Die Sicherheitsattribute der Blätter können aber beispielsweise manuell veränderbar sein. Ebenso kann der Graph oder dessen Struktur dem Algorithmus als Input gegeben oder durch den Algorithmus nachgebildet oder implementiert werden. Der Algorithmus kann beispielsweise automatisch bestimmen, welche der Knoten des Graphen Blätter oder innere Knoten oder Wurzelknoten sind und/oder wie diese durch Kanten des Graphen miteinander verbunden sind. Dadurch können beispielsweise automatisch Start- und/oder Endpunkte für den Algorithmus, also die Berechnung oder Aktualisierung der Sicherheitsattribute der übrigen Knoten und somit letztlich des Sicherheitsstatus der Software beziehungsweise für das jeweilige Softwareprojekt ermittelt werden. Eine solche automatische Berechnung oder Aktualisierung, also die auf dem Graphen und den Regeln basierende automatische Evaluierung des Software-Sicherheitsstatus, kann einen weiteren Verfahrensschritt des erfindungsgemäßen Verfahrens oder ein eigenes Verfahrens als weiteren Aspekt der vorliegenden Erfindung bilden.
Das erfindungsgemäße Verfahren kann also um wenigstens einen entsprechenden Algorithmus beziehungsweise das Bereitstellen oder Anwenden wenigstens eines entsprechenden Algorithmus ergänzt werden, der das aktuelle Sicherheitsattribut, also den aktuellen Sicherheitsstatus (englisch: safety approval) automatisch bestimmen oder auswerten kann, beispielsweise für einzelne Knoten oder Softwareteile. Ein derartiger Algorithmus kann beispielsweise entlang der Struktur des Graphen entsprechende Auswertungen durchführen, und dann beispielsweise automatisch Fragen dazu beantworten beziehungsweise Aussagen dazu treffen, wie weit der aktuelle Sicherheitsstatus eines Softwareteils oder des gesamten Softwaresystems von einem vorgegebenen Ziel entfernt ist, welche Teile oder Pfade des Graphen beziehungsweise des Softwaresystems bezüglich einer Veränderung des Sicherheitsstatus des gesamten Softwaresystems oder des Wurzelknotens des Graphen kritisch oder ausschlaggebend sind oder dergleichen mehr.
Die jeweils für die übrigen Knoten bestimmten Sicherheitsattribute können in den entsprechenden Datenfeldern der Knoten gespeichert werden. Damit müssen die Sicherheitsattribute, also die jeweils aktuellen Sicherheitseinstufungen nicht im Quellcode des Softwaresystems oder -projekts gespeichert werden, was letztlich mehr Flexibilität und eine vereinfachte Handhabbarkeit und Überprüfbarkeit ermöglicht. Beispielsweise können so konsistent weitere Daten oder Faktoren für die Bestimmung der Sicherheitsattribute berücksichtigt werden, die außerhalb des Quellcodes des Softwaresystems liegen, wie etwa Eigenschaften oder eventuell gegebene Redundanz einer Hardware, die für die in den Softwareteilen implementierten Funktionen verwendet wird oder werden soll. Zudem kann so der Sicherheitsstatus beispielsweise durch Personen abgefragt oder diesen offengelegt werden, die keinen direkten Einblick in den Quellcode erhalten sollen.
Auch für die übrigen Knoten, zumindest für die inneren Knoten oder einen Teil davon, können manuell oder von außen deren Sicherheitsattribute vorgegeben oder gesetzt werden. Derartige vorgegebene Sicherheitsattribute können dann beim Bestimmen der Sicherheitsattribute für den Graphen automatisch berücksichtigt, insbesondere priorisiert verwendet werden.
Dadurch, dass zumindest für alle Blätter des Graphen ein aktueller Sicherheitsstatus vorgegeben oder definiert ist, kann die automatische Auswertung oder Bestimmung des Gesamt-Sicherheitsstatus oder des Sicherheitsstatus einzelner Äste des Graphen oder einzelner Softwareteile besonders zuverlässig und genau durchgeführt werden. Dazu können die aktuellen Sicherheitsstatus der Blätter entlang der Struktur des Graphen gemäß den entsprechenden Regeln in definierter und reproduzierbarer Weise kombiniert werden, sodass letztlich für alle Knoten des Graphen der jeweilige aktuelle Sicherheitsstatus, also das jeweilige aktuelle Sicherheitsattribut, bestimmt werden kann, auch wenn dieses für einen bestimmten inneren Knoten des Graphen nicht vorgegeben ist
Das Softwaresystem kann beispielsweise mittels einer Versionsverwaltung in einem zentralen Projektarchiv verwaltet werden. An einer Entwicklung des Softwaresystems beteiligte Personen können dann Softwareaktualisierungen, beispielsweise aktualisierte Softwareteile, an die Versionsverwaltung beziehungsweise das Projektarchiv übermitteln. Bei einer derartigen Übermittlung kann ein jeweiliger aktueller Sicherheitsstatus für die jeweilige Übermittlung oder Aktualisierung angegeben, also mitübermittelt werden. Dies kann dann automatisch ausgelesen und entsprechend in dem Graphen hinterlegt oder aktualisiert werden. Mit anderen Worten kann also der jeweilige aktuelle Sicherheitsstatus beziehungsweise ein jeweiliges aktuelles Sicherheitsattribut beispielsweise aus einem jeweiligen aktuellen, dem Softwaresystem hinzugefügten Code oder Softwareteil beziehungsweise einem jeweiligen Commit in ein entsprechendes Software-Repository ausgelesen und dann automatisch in dem Graphen eingetragen oder aktualisiert werden. Auf eine solche Aktualisierung hin, kann das jeweilige aktualisierte Sicherheitsattribut entlang der Struktur des Graphen automatisch propagiert werden. Es kann also jeweils eine automatische Aktualisierung der Sicherheitsattribute in dem Graphen, also des Sicherheitsstatus durchgeführt werden. Dies kann zumindest für einen jeweiligen aktualisierten Ast des Graphen erfolgen. Somit kann auf besonders einfache und zuverlässige Weise stets der tatsächliche Software-Sicherheitsstatus für das Softwaresystem insgesamt ebenso wie für einzelne Softwareteile in dem Graphen angegeben, also bekannt oder abrufbar sein. Da dies automatisiert oder algorithmisch durchgeführt werden kann, ist dies auch für zumindest nahezu beliebig große Softwaresysteme oder Softwareprojekte mit besonders hoher Frequenz oder Regelmäßigkeit, beispielsweise bei jeder Aktualisierung eines oder mehrerer Softwareteile oder Codeabschnitte des Softwaresystems, und gleichzeitig mit im Vergleich zu herkömmlichen Verfahren reduzierter Fehleranfälligkeit möglich.
Die hier vorgeschlagene Kombination aus dem Graphen und den Sicherheitsattributen mit den vorgegebenen Regeln, insbesondere in einer formalisierten Sprache zum automatischen oder maschinellen Anwenden der Regeln, stellt eine vorteilhafte technische Lösung oder Grundlage dar, mit der beziehungsweise auf Basis derer der Software-Sicherheitsstatus eines jeweiligen Software- oder Entwicklungsprojekts ebenso wie der aktuelle Sicherheitsstatus eines jeden Elements davon reproduzierbar, automatisch sowie bei Bedarf kontinuierlich oder regelmäßig besonders aufwandsarm bestimmt werden kann. Die entsprechenden Sicherheitsstatus sowie gegebenenfalls darauf basierende Auswertungen oder weiterführende Fragen oder Aussagen können beispielsweise bei jeder Änderung des Softwaresystems, beispielsweise eines Softwareteils, automatisch aktualisiert werden. Damit können durch die vorliegende Erfindung letztendlich die Sicherheit und Zuverlässigkeit nahezu beliebig komplexer Software- oder Entwicklungsprojekte bereits in deren Entwicklungsphase im Vergleich zu herkömmlichen Methoden signifikant verbessert werden. Dies kann dabei mit deutlich weniger Zeit- und Kostenaufwand sowie deutlich weniger Einsatz manueller Arbeit erreicht werden.
In vorteilhafter Ausgestaltung der vorliegenden Erfindung sind die Regeln zum Kombinieren der Sicherheitsattribute in einer regeldefinierenden logischen Programmiersprache angegeben, also verfasst oder formuliert. Ein Beispiel für eine solche logische Programmiersprache ist Prolog. Damit kann eine logische, deklarative, gegebenenfalls constraint-basierte Formulierung der Regeln realisiert werden. Eine derartige Struktur passt besonders gut zu den Gegebenheiten und Anforderungen, die sich bei der technischen Umsetzung der vorliegenden Erfindung ergeben. Durch die Verwendung einer derartigen logischen Programmiersprache können die vorliegende Erfindung also besonders einfach, aufwandsarm und intuitiv realisiert werden. Grundsätzlich könnte aber jede Turing-vollständige Programmiersprache verwendet werden. Somit ist vorteilhaft eine ausreichende Flexibilität gegeben, um die vorliegende Erfindung in unterschiedlichen Szenarien anwenden zu können.
In weiterer vorteilhafter Ausgestaltung der vorliegenden Erfindung geben die Sicherheitsattribute ein jeweiliges standardisiertes Sicherheitslevel, insbesondere ein ASIL, an und die Regeln werden durch entsprechende für die Sicherheitslevel vorgegebene Dekompositionsregeln, insbesondere ASIL-Dekompositionsregeln, bestimmt. Die hier vorgegebenen Regeln können einen also beispielsweise den ASIL-Dekompositionsregeln gemäß ISO 26262 entsprechen, diese umfassen oder aus diesen abgeleitet sein. Auf diese Weise kann die vorliegende Erfindung standardkonform direkt auf Softwaresysteme oder Entwicklungsprojekte im Bereich der Fahrzeugtechnik angewendet werden. Ebenso kann die vorliegende Erfindung aber auf andere Sicherheitssysteme oder andere technische Bereiche angewendet werden.
In weiterer vorteilhafter Ausgestaltung der vorliegenden Erfindung wird der Graph, insbesondere automatisch, basierend auf einem Abhängigkeitsgraphen (englisch: build dependency graph) erstellt, der automatisch durch ein Software-Erstellungswerkzeug (englisch, fachsprachlich: Build-System) bereitgestellt wird, oder automatisch oder teilautomatisch aus dem Quelltext des Softwaresystems beziehungsweise der Softwareteile, insbesondere aus dessen Header-Dateien, generiert. Mit anderen Worten kann der Abhängigkeitsgraph also als Grundlage oder Ausgangspunkt zur Erstellung des Graphen automatisch aus dem Quelltext generiert werden. Ein Beispiel für ein entsprechendes Software-Erstellungswerkzeug in diesem Sinne ist etwa das Build-Werkzeug BAZEL, das automatisch Abhängigkeitsgraphen generieren und ausgeben kann. Ebenso können beispielsweise Abhängigkeiten, Verweise, Referenzen, Inklusionen, Deklarationen und/oder dergleichen mehr, die in verschiedenen Dateien oder Softwareteilen bzw. Softwaremodulen des Softwaresystems enthalten oder angegeben sind, automatisch ausgewertet und in eine Graph- oder Baum-Struktur, nämlich letztlich den Graphen, umgesetzt werden.
In jedem Fall kann der Graph hier also automatisch erzeugt werden, wodurch sich ein besonders hoher Automatisierungsgrad der vorliegenden Erfindung ergibt. Zudem kann durch die hier vorgeschlagene automatische Detektion und Berücksichtigung von Abhängigkeiten innerhalb des Softwaresystems, beispielsweise zwischen verschiedenen Softwareteilen, also Softwaremodulen oder Dateien des Softwaresystems, die Sicherheit und Zuverlässigkeit des jeweiligen Software- oder Entwicklungsprojekts, also des Softwaresystems insgesamt, weiter verbessert werden. Dies ist insbesondere im Vergleich zu bisherigen Systemen zum Evaluieren oder Verwalten des Sicherheitsstatus zu sehen, bei denen entsprechende Abhängigkeiten oftmals manuell erkannt und berücksichtigt werden müssen, was ein offensichtlich aufwendiger und fehleranfälliger Prozess ist. Sofern nicht der durch das Software-Erstellungswerkzeug erzeugte Abhängigkeitsgraph direkt als der Graph für das vorliegende Verfahren verwendet wird, kann der Abhängigkeitsgraph zum Erzeugen des letztendlichen Graphen beispielsweise um die genannten Datenfelder, entsprechende Annotationen oder Strukturen für die Sicherheitsattribute, deren Kombination und/oder die Regeln und/oder dergleichen mehr ergänzt werden.
In weiterer vorteilhafter Ausgestaltung der vorliegenden Erfindung wird als Parameter für wenigstens eine der vorgegebenen Regeln ein jeweiliger aktueller Erfüllungszustand wenigstens einer vorgegebenen Sicherheitsanforderung für wenigstens einen der Softwareteile und/oder der Knoten vorgegeben und zum Bestimmen der Sicherheitsattribute der übrigen Knoten berücksichtigt. Mit anderen Worten kann zum Bestimmen der Sicherheitsattribute der übrigen Knoten auch ein jeweiliger aktueller Erfüllungszustand von vorgegebenen Sicherheitsanforderungen für einen oder mehrere der Softwareteile und/oder der Knoten, insbesondere der dem jeweiligen übrigen Knoten hierarchisch untergeordneten Knoten, automatisch berücksichtigt werden. Dabei kann eine solche Sicherheitsanforderungen insbesondere eine Störungsfreiheit zwischen zwei, insbesondere hierarchisch gleichrangigen oder durch eine Kante des Graphen miteinander verbundenen, Knoten beziehungsweise den diesen zugeordneten Softwareteilen, eine jeweilige MPU-Aktivierung oder eine jeweilige Compiler-Qualifizierung betreffen. Ein Erfüllungszustand kann also beispielsweise angeben, ob für zwei Softwareteile oder Knoten eine gegenseitige Störungsfreiheit gegeben bzw. sichergestellt ist, eine Speicherpartitionierung oder Speicherabsicherung aktiv ist, eine Compiler-Qualifizierung vorliegt, oder dergleichen mehr. Die Sicherheitsanforderungen beziehungsweise deren jeweiliger Erfüllungszustand können also als weiterer Input für die Bestimmung des Sicherheitsstatus, also beispielsweise für einen entsprechenden Algorithmus zum Bestimmen oder Aktualisieren der Sicherheitsattribute entlang des Graphen, dienen.
Die Sicherheitsanforderungen geben spezifische Anforderungen an, die erfüllt werden müssen, beispielsweise durch ein Softwaremodul oder für eine Zuordnung eines bestimmten Sicherheitsattributs zu einem Softwaremodul oder Knoten. Die Erfüllungszustände geben an, ob diese Sicherheitsanforderungen erfüllt sind oder nicht. Es kann also beispielsweise für das Bestimmen des zutreffenden Sicherheitsattributs für einen Elternknoten berücksichtigt werden, ob beziehungsweise dass sich dessen von ihm abhängige hierarchisch direkt untergeordnete Kinderknoten gegenseitig nicht beeinflussen oder sich der Elternknoten und wenigstens einer seiner Kinderknoten gegenseitig nicht beeinflussen, zumindest hinsichtlich ihrer Sicherheitsattribute. Dies kann beispielsweise Voraussetzung dafür sein, dass ein niedrigeres oder schwächeres Sicherheitsattribut, beispielsweise ein kleineres ASIL, eines Kinderknotens nicht zu einer Reduzierung des Sicherheitsattributs oder ASIL des Elternknotens führt.
Ist also für oder zwischen zwei Knoten eine Störungsfreiheit gegeben, beeinflussen sich diese Knoten beziehungsweise deren Sicherheitsattribute also nicht, so kann dementsprechend beispielsweise ein niedrigeres ASIL des einen Knotens keinen Einfluss auf das höhere ASIL des anderen Knotens haben. Daher kann dann beispielsweise eine Speicherschutzeinheit (englisch: Memory Protection Unit) oder eine Überwachungseinheit (englisch: Watchdog) oder dergleichen aktiviert werden. Durch die automatische Berücksichtigung von derartigen Sicherheitsanforderungen beziehungsweise deren jeweiligem Erfüllungszustand kann vorteilhaft eine besonders flexible und detaillierte Bestimmung der jeweiligen Sicherheitsattribute und letztlich des gesamten Software-Sicherheitsstatus realisiert werden.
In weiterer vorteilhafter Ausgestaltung der vorliegenden Erfindung werden zumindest die Regeln aus einem in maschinenlesbarer Form bereitgestellten technischen Sicherheitskonzept abgeleitet, insbesondere automatisch oder teilautomatisch. Ebenso können aus einem derartigen maschinenlesbaren technischen Sicherheitskonzept (TSC, englisch: Technical Safety Concept) die genannten Sicherheitsanforderungen oder - bedingungen, insbesondere automatisch oder teilautomatisch, ausgelesen oder abgeleitet werden. Ein solches technisches Sicherheitskonzept kann sicherheitsrelevante Relationen zwischen Komponenten, Funktionen oder Modulen, beispielsweise einer dem Softwaresystem zugrunde liegenden oder durch das Softwaresystem implementierten Softwarearchitektur, angeben. Derartige Funktionen, Komponenten oder Module, im Folgenden zusammenfassend als Komponenten der Softwarearchitektur bezeichnet, können in diesem Sinne beispielsweise logische Elemente oder Teilsysteme beziehungsweise von einer konkreten Implementierung abstrahierte technische Funktionen sein oder betreffen, beispielsweise bestimmte Fahraufgaben, eine Objekterkennung für die Kollisionsvermeidung oder dergleichen mehr.
Die sicherheitsrelevanten Relationen können beispielsweise Abhängigkeiten oder Beeinflussungen der Sicherheit einer Komponente oder einer Funktion von einer oder mehreren anderen Komponenten oder Funktionen angeben. So kann beispielsweise angegeben sein, dass eine erste Komponente nur dann sicher ist oder bestimmte Sicherheitsanforderungen erfüllt, wenn eine zweite Komponente sicher ist oder bestimmte Sicherheitsanforderungen erfüllt oder beispielsweise dass beziehungsweise wie eine Veränderung eines Sicherheitszustands oder Sicherheitsattributs einer Komponente sich auf den Sicherheitszustand oder das Sicherheitsattribut einer anderen Komponente auswirken kann.
Eine Komponente oder eine technische Funktion, die in dem technischen Sicherheitskonzept enthalten oder beschrieben ist, kann beispielsweise durch jeweils ein oder mehrere Softwaremodule des Softwaresystems implementiert sein.
Grundsätzlich können beispielsweise die Regeln aus dem TSC unabhängig von dessen Form abgeleitet oder extrahiert werden, je nach Form oder Struktur des TSC beispielsweise manuell. Dadurch, dass das TSC hier jedoch in maschinenlesbarer Form vorliegt, also beispielsweise in einem maschinenlesbaren Format und/oder in einer maschinenlesbaren Modellierungssprache formuliert ist, können die Regeln oder gegebenenfalls weitere Größen, wie etwa die genannten Sicherheitsanforderungen, automatisch oder halbautomatisch aus dem TSC abgeleitet oder extrahiert werden. Ein entsprechender halbautomatischer Prozess kann beispielsweise softwaregeführt oder softwareunterstützt ablaufen. Bevorzugt kann das TSC in der genannten regeldefinierenden logischen Programmiersprache gegeben sein.
Je nach Struktur oder Ausgestaltung kann zunächst aus dem technischen Sicherheitskonzept, insbesondere automatisch oder teilautomatisch, durch eine Zuordnung zwischen dessen Elementen, Einträgen oder Komponenten und den Softwaremodulen ein Sicherheitskonzeptgraph erzeugt werden, dessen Struktur bereits zumindest im Wesentlichen der letztendlichen Struktur des Graphen oder der Struktur eines automatisch für das Softwaresystem erzeugten Abhängigkeitsgraphen entspricht. Mit anderen Worten kann also eine architekturbasierte Deduktion (englisch: architectural deduction) durchgeführt werden, um gegebenenfalls gröbere oder abstraktere Elemente, technische Funktionen oder Konzepte oder Komponenten, die in dem technischen Sicherheitskonzept angegeben oder definiert sind, zu unterteilen oder aufzuteilen, also auf ein feineres oder detaillierteres Niveau herunterzubrechen, auf dem eine jeweilige Implementierung durch einzelne Softwaremodule, insbesondere direkt, möglich ist.
Der so erzeugte Sicherheitskonzeptgraph kann dann beispielsweise, insbesondere automatisch, direkt auf den automatisch erzeugten Abhängigkeitsgraphen abgebildet oder mit diesem in Überdeckung gebracht, also mit diesem kombiniert werden. Dabei können Elemente oder Komponenten des TSC jeweils zu einem Knoten oder einer Kante des Abhängigkeitsgraphen zugeordnet werden, beispielsweise je nachdem ob sie einzelne Funktionen oder Relationen oder Beziehungen zwischen zwei Funktionen oder Softwaremodulen oder dergleichen beschreiben oder definieren. Eine solche Kombination kann dann als Grundlage zum Erzeugen des Graphen für das Bestimmen der Sicherheitsattribute verwendet werden. Auf diese Weise kann der Graph besonders zuverlässig zumindest teilautomatisiert erzeugt werden und/oder besonders genau und detailliert entsprechende Strukturen und Eigenschaften des jeweiligen Software- oder Entwicklungsprojekts abbilden oder widerspiegeln.
Weiter kann zum Bestimmen des aktuellen Sicherheitsstatus oder Sicherheitsattribut zumindest eines Elements oder einer Komponente des technischen Sicherheitskonzept derjenige Teil des Graphen automatisch bestimmt werden, der diesem Element oder dieser Komponente zugehörige Softwaremodule repräsentiert oder enthält. Zumindest die Knoten sowie gegebenenfalls die Kanten dieses Teils des Graphen werden dann automatisch gemäß den diesen zugeordneten vorgegebenen Regeln entlang der Struktur des Graphen evaluiert. Mit anderen Worten kann hier also eine architekturbasierte Aggregation (englisch: architectural aggregation) durchgeführt werden, bei der die feiner aufgelösten oder detaillierteren Strukturen des Graphen beziehungsweise des diesem zugrunde liegenden automatisch erzeugten Abhängigkeitsgraphen gemäß dem technischen Sicherheitskonzept beziehungsweise einer Struktur der jeweiligen Softwarearchitektur zusammengefasst, also auf ein entsprechend gröberes Level oder Niveau abstrahiert werden. Da die Regeln des Graphen und dessen Struktur, also letztlich die in dem technischen Sicherheitskonzept definierten sicherheitsrelevanten Relationen automatisch korrekt berücksichtigt werden, kann so automatisch der aktuelle Sicherheitsstatus von Elementen oder Komponenten des technischen Sicherheitskonzept beziehungsweise von Komponenten der Softwarearchitektur bestimmt werden, die nicht notwendigerweise durch einzelne Knoten oder Softwaremodule in dem Graphen repräsentiert sind. Hier ist mit anderen Worten also eine Rücktransformation von der Software-, Implementierungs- oder Codeebene zur abstrakteren oder eher konzeptionellen Ebene oder zum Niveau technischer Funktionen oder Anforderungen mit korrekter automatisierter Bestimmung des jeweiligen Sicherheitsstatus oder Sicherheitsattribut möglich. Dadurch kann der aktuelle Sicherheitszustand oder Sicherheitsstatus des jeweiligen Software- oder Entwicklungsprojekts also auf unterschiedlichen Ebenen oder Niveaus automatisch bestimmt und gegebenenfalls ausgegeben werden, wodurch sich vorteilhaft eine besonders einfache Nachvollziehbarkeit und Zuverlässigkeit bei der Bewertung der Sicherheit ergeben können.
In weiterer vorteilhafter Ausgestaltung der vorliegenden Erfindung können die Sicherheitsattribute bzw. die aktuellen Sicherheitsstatus zumindest eines Teils der übrigen Knoten vorgegeben werden, also beispielsweise manuell veränderbar oder editierbar sein, wobei diese übrigen Knoten dann ein Signaturdatenfeld zum Identifizieren einer jeweiligen Person, die das jeweilige Sicherheitsattribut bzw. den jeweiligen Sicherheitsstatus vorgegeben hat, aufweisen. Entsprechende vorgegebene Sicherheitsattribute oder Sicherheitsstatus werden dann beim Bestimmen der Sicherheitsattribute beziehungsweise beim Bestimmen des Sicherheitsstatus für das Softwaresystem, insbesondere priorisiert, automatisch berücksichtigt. Es können hier also die Sicherheitsattribute oder Sicherheitsstatus von übrigen Knoten, insbesondere von inneren Knoten, des Graphen manuell oder von außen vorgegeben oder gesetzt werden. Dies kann beispielsweise vorteilhaft sein, wenn sich ein jeweiliges Sicherheitsattribut oder ein jeweiliger Sicherheitsstatus durch außerhalb des jeweiligen Softwareteils oder des Softwaresystems liegende Gründe oder Faktoren ändert. Derartige nicht softwarebasierte Gründe können beispielsweise hardware- oder anwendungsspezifisch sein, wie etwa ein Einbau oder eine zugesicherte Verwendung redundanter Hardware oder mehrerer auf unterschiedlichen Funktionsprinzipien basierender Hardwareeinrichtungen, entsprechender Sensoren und/oder dergleichen mehr. Durch ein entsprechendes Signaturdatenfeld, das beispielsweise ausgefüllt werden muss, um eine Änderung des jeweiligen Sicherheitsattributs zu ermöglichen, kann vorteilhaft eine verbesserte Nachverfolgbarkeit oder Verantwortlichkeit bezüglich sicherheitsrelevanter Eigenschaften oder Änderungen erreicht werden. Dies kann letztlich zur weiter verbesserten Sicherheit und Zuverlässigkeit für das jeweilige Softwaresystem beziehungsweise die Bestimmung von dessen Sicherheitsstatus beitragen. Ebenso kann beispielsweise eine der genannten Sicherheitsanforderungen sein, dass das Signaturdatenfeld eines bestimmten Knotens ausgefüllt ist, um diesem Knoten oder einem diesem hierarchisch übergeordneten Knoten ein bestimmtes Sicherheitsattribut zuweisen zu können. Zusätzlich oder alternativ können ebenso die Blätter des Graphen entsprechende Signaturdatenfelder aufweisen. Dies kann besonders vorteilhaft sein, da die Sicherheitsattribute der Blätter in jedem Fall vorgegeben werden und nicht automatisch bestimmt oder berechnet werden.
In weiterer vorteilhafter Ausgestaltung der vorliegenden Erfindung ist für die Softwareteile und/oder für die Kanten des Graphen ein jeweiliges zu erreichendes Ziel-Sicherheitsattribut, insbesondere ein Ziel-ASIL, vorgegeben. Ein solches Ziel-Sicherheitsattribut gibt dabei einen jeweiligen Sicherheitsstatus an, der bestimmungs- oder spezifikationsgemäß im Rahmen der Entwicklung des Softwaresystems letztlich erreicht werden soll. Diese Ziel-Sicherheitsattribute können bevorzugt in dem Graphen, beispielsweise dem oder einem entsprechenden weiteren Datenfeld, gespeichert sein oder werden. Durch die Angabe oder Vorgabe der Ziel-Sicherheitsattribute kann vorteilhaft ein besonders einfacher, insbesondere automatisierter, Vergleich mit einem jeweiligen aktuellen Ist-Sicherheitsattribut oder Ist-Sicherheitszustand und somit ein automatisches Treffen oder Ausgeben einer relativen Bewertung des aktuellen Sicherheitsstatus ermöglicht werden. So kann beispielsweise automatisch ermittelt beziehungsweise ausgegeben werden, ob ein jeweiliges Entwicklungsziel, zumindest hinsichtlich der Sicherheit, erreicht ist, für welchen Anteil der Softwareteile dies der Fall ist oder wie weit der aktuelle Sicherheitsstatus von einem Ziel-Sicherheitsstatus entfernt ist. Dies kann hier automatisiert und jeweils zumindest nahezu in Echtzeit aktualisiert erfolgen, wodurch letztlich ein genauerer und zuverlässiger Überblick über den jeweils aktuellen Sicherheitsstatus ermöglicht wird.
In weiterer vorteilhafter Ausgestaltung der vorliegenden Erfindung wird durch Auswerten der aktuellen Sicherheitsattribute der Knoten des Graphen unter Berücksichtigung der vorgegebenen Regeln und der Struktur des Graphen mittels eines vorgegebenen Algorithmus automatisch ein minimaler Satz von Knoten beziehungsweise Softwareteilen, also Softwaremodulen bestimmt, für die eine - insbesondere minimale - Verbesserung ihres Sicherheitsattributs zu einer Verbesserung des Sicherheitsattributs des Wurzelknotens des Graphen und/oder zu einer Verbesserung des Sicherheitsstatus des Softwaresystems insgesamt führen würde. Eine minimale Verbesserung eines Sicherheitsattribut kann beispielsweise eine Hochstufung um genau ein ASIL, also auf das jeweils nächsthöhere ASIL bedeuten. Insbesondere wenn nur eine begrenzte oder relativ kleine Anzahl verschiedener Sicherheitsstatus möglich ist, also beispielsweise nur eine vorgegebene begrenzte Anzahl verschiedener Sicherheitsattribute vergeben werden kann, wie dies etwa bei Verwendung der ASIL als Sicherheitsattribute der Fall ist, kann der minimale Satz von Knoten oder Softwareteilen beispielsweise durch Auswerten eines gesamten möglichen Kombinationsraums und jeweiliges Bestimmen der resultierenden Sicherheitsstatus oder Sicherheitsattribute ermittelt werden (brute force Ansatz).
Ein solcher Kombinationsraum kann dabei alle Kombinationen von verschiedenen Sicherheitsattributen der Knoten oder Softwareteile umfassen, bei denen das Sicherheitsattribut wenigstens eines Knotens oder Softwareteils höher oder stärker als dessen tatsächliches aktuelles Sicherheitsattribut ist und die Sicherheitsattribute aller anderen Knoten oder Softwareteile wenigstens deren tatsächlichem aktuellem Sicherheitsattribut entspricht.
Analog kann ein entsprechender minimaler Satz von Knoten beziehungsweise Softwaremodulen bestimmt werden, für den eine Verschlechterung der Sicherheitsattribute oder zu einer Verschlechterung des Sicherheitsattributs des Wurzelknotens oder zu einer Verschlechterung des Sicherheitsstatus des gesamten Softwaresystems führen würde.
Mit anderen Worten können also auf diese Weise durch automatische Variation der Sicherheitsattribute und entsprechende Auswertung der resultierenden Sicherheitsattribute beziehungsweise des resultierenden Gesamt-Sicherheitsstatus unter Sicherheitsgesichtspunkten besonders relevante, also kritische Knoten beziehungsweise Softwaremodule ermittelt werden. Dies kann vorteilhaft eine zielgenaue Allokation von Entwicklungsressourcen, also eine zielgenaue Weiterentwicklung von im jeweils aktuellen Moment oder Entwicklungszustand besonders sicherheitskritischen Teilen des Softwaresystems und damit letztlich eine besonders schnelle und effiziente Verbesserung des Gesamt-Sicherheitsstatus ermöglichen. Aufgrund komplexer Regeln und Abhängigkeiten ist die Ermittlung eines entsprechenden minimalen Satzes derartiger kritischer Knoten oder Softwaremodule manuell nicht immer ohne Weiteres möglich, sodass durch die vorliegend vorgeschlagene Automatisierung ein signifikanter Fortschritt erzielt werden kann.
Ein weiterer Aspekt der vorliegenden Erfindung ist eine Datenverarbeitungseinrichtung, die einen Prozessor und einen damit verbundenen Datenspeicher umfasst. Die Datenverarbeitungseinrichtung ist dazu eingerichtet, basierend auf dem erfindungsgemäßen Verfahren automatisch einen Software-Sicherheitsstatus für ein vorgegebenes Softwaresystem oder zumindest für einen Teil davon, beispielsweise für ein Softwareteil, also ein Softwaremodul oder eine Gruppe von Softwareteilen, die einer abstrakten Funktion, etwa eines Assistenzsystems oder eines entsprechenden Fahrzeugs, zugeordnet sind, diese also implementieren, zu bestimmen. Die Datenverarbeitungseinrichtung ist mit anderen Worten also zum Auswerten der Sicherheitsattribute entlang des Graphen gemäß den vorgegebenen Regeln eingerichtet.
Dazu kann auf dem Datenspeicher beispielsweise der im Zusammenhang mit dem erfindungsgemäßen Verfahren genannte Algorithmus beziehungsweise ein entsprechender Programmcode oder ein entsprechendes Computerprogramm gespeichert sein, der beziehungsweise das mittels des Prozessors zum Bestimmen des Software-Sicherheitsstatus ausführbar ist. Ebenso kann die erfindungsgemäße Datenverarbeitungseinrichtung entsprechend zum, insbesondere automatischen oder teilautomatische, Durchführen eines oder mehrerer der übrigen im Zusammenhang mit dem erfindungsgemäßen Verfahren genannten Verfahrensschritte, Abläufe oder Prozesse eingerichtet sein. So kann die Datenverarbeitungseinrichtung beispielsweise dazu eingerichtet sein, automatisch oder teilautomatisch aus einem vorgegebenen maschinenlesbaren technischen Sicherheitskonzept die Regeln abzuleiten oder zu extrahieren, eine architekturbasierte Deduktion oder Aggregation durchzuführen und/oder dergleichen mehr. Mittels der Datenverarbeitungseinrichtung können letztlich also automatisch verschiedene Sicherheitsaspekte oder sicherheitsrelevante Fragestellungen für das vorgegebenes Softwaresystem automatisch oder teilautomatisch evaluiert werden.
Der Datenspeicher mit dem darauf gespeicherten Programmcode oder Computerprogramm sowie dieses Computerprogramm selbst, das entsprechende Verfahrensschritte oder Steueranweisungen codiert oder repräsentiert, also implementiert, können ihrerseits eigenständige Aspekte der vorliegenden Erfindung sein. Das entsprechende Verfahren ebenso wie das eingangs erläuterte erfindungsgemäße Verfahren zum Ermöglichen der automatischen Evaluierung des Software-Sicherheitsstatus können jeweils zumindest teilweise computerimplementiert sein.
Weitere Merkmale der Erfindung können sich aus den Ansprüchen, den Figuren und der Figurenbeschreibung ergeben. Die vorstehend in der Beschreibung genannten Merkmale und Merkmalskombinationen sowie die nachfolgend in der Figurenbeschreibung und/oder in den Figuren alleine gezeigten Merkmale und Merkmalskombinationen sind nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar, ohne den Rahmen der Erfindung zu verlassen.
Die Zeichnung zeigt in der einzigen Figur ein Übersichtsschema zur Veranschaulichung einer automatischen Sicherheitsevaluierung eines Softwareprojekts.
Für Software- oder Entwicklungsprojekte ist die Sicherheit oftmals von entscheidender Bedeutung. Dazu gehört auch, dass die Sicherheit für einzelne Teile des jeweiligen Projekts sowie für das gesamte Projekt bestimmt beziehungsweise nachverfolgt werden kann. Dies kann beispielsweise anhand einer jeweiligen Sicherheitszulassung oder Sicherheitsfreigabe (englisch: safety approval) oder einer Sicherheitskonformität (englisch: safety compliance) beziehungsweise einer Einhaltung oder Erfüllung entsprechender Sicherheitsbestimmungen oder -vorgaben erfolgen. Im vorliegenden Beispiel können diese etwa durch ISO-26262 definiert sein.
Die Sicherheit oder Sicherheitszulassung, also der Gesamt-Sicherheitsstatus oder - zustand des gesamten Software- oder Entwicklungsprojekts kann sich hierarchisch aus Sicherheitszulassungen oder -zuständen aller Teile des Projekts zusammensetzen. Diese können dann nach einem vorgegebenen Schema aggregiert, also kombiniert oder zusammengefasst werden. Dazu ist vorliegend ein entsprechendes technisches Sicherheitskonzept 10, beispielsweise in Form eines Sicherheitsdokuments 12 bereitgestellt. Das Sicherheitsdokument 12 kann insbesondere ein digitales Dokument, beispielsweise im portable document format (pdf) oder dergleichen, sein. Darin können beispielsweise Angaben zu ASILs und gegebenenfalls der Störungsfreiheit und/oder anderer Sicherheitsanforderungen enthalten sein. Das Sicherheitskonzept 10 kann ebenso angeben, wie technische Konzepte, Komponenten oder Funktionen des jeweiligen Projekts hinsichtlich ihrer Level funktionaler Sicherheit unter welchen Bedingungen kombiniert werden können beziehungsweise welches funktionale Sicherheitslevel, also welcher Sicherheitszustand daraus jeweils resultiert. Beispielsweise kann eine Komponente mit dem aktuellen funktionalen Sicherheitslevel oder Sicherheitszustand ASIL-B mit einer anderen Komponente kombiniert oder zusammengefasst werden, die ein aktuelles funktionales Sicherheitslevel von ASIL-QM aufweist. Daraus kann sich dann für die Kombination oder Aggregation dieser beiden Komponenten das funktionale Sicherheitslevel ASIL-B ergeben unter einer in dem Sicherheitskonzept 10 angegebenen Beziehung, wonach diese beiden Komponenten frei von gegenseitigen Störeinflüssen sind. Das Sicherheitskonzept 10 kann mit anderen Worten also Sicherheitsbeziehungen zwischen logischen oder funktionalen Subsystemen des jeweiligen Projekts auf einem höheren oder abstrakteren Level oder Niveau angeben.
Das Projekt umfasst weiter ein Softwaresystem, das eine Codebasis darstellt, also Quellcode beziehungsweise codebasierte Implementierungen der auf dem höheren oder abstrakteren Level definierten Komponenten oder Funktionen des Projekts enthält, also beispielsweise entsprechende digitale Dateien umfasst. Dieses Softwaresystem kann beispielsweise mittels einschlägiger Entwicklungswerkzeuge verwaltet werden. Beispielsweise aus einem solchen Entwicklungswerkzeug heraus kann ein Abhängigkeitsgraph 14 automatisch oder teilautomatisch erzeugt werden, der hier ebenfalls bereitgestellt wird. Der Abhängigkeitsgraph 14 beschreibt oder repräsentiert software- oder codeseitige Abhängigkeiten von als Teil des Softwaresystems implementierten Softwareteilen, hier bezeichnet als Softwaremodule 16. Diese Softwaremodule 16 sind dabei als Knoten des Abhängigkeitsgraphen 14 repräsentiert, während deren Abhängigkeiten oder Beziehungen hier durch Kanten 18 repräsentiert sind, welche die Knoten, also die Softwaremodule 16 miteinander verbinden.
In analoger Weise wird vorliegend aus dem Sicherheitsdokument 12 ein Sicherheitskonzeptgraph 20 erzeugt. Darin repräsentieren Knoten des Sicherheitskonzeptgraphen 20 logische Komponenten 22 des jeweiligen Projekts. Sicherheitsrelevante Relationen 24 zwischen diesen logischen Komponenten 22 sind hier als Kanten des Sicherheitskonzeptgraphen 20 repräsentiert, die dessen Knoten miteinander verbunden. Der Sicherheitskonzeptgraph 20 kann hier insbesondere in einem maschinenlesbaren Format oder einer maschinenlesbaren Form vorliegen. Dies kann auch bereits für das Sicherheitsdokumente 12 gelten.
Der Sicherheitskonzeptgraph 20 beziehungsweise dessen Knoten können eine Architektur oder Struktur des jeweiligen Projekts auf dem - von dem Implementierungs- oder Code-Niveau des Abhängigkeitsgraphen 14 abstrahierten - höheren Level oder Niveau beschreiben oder repräsentieren. Davon ausgehend wird durch eine architekturale, also architekturbasierte Deduktion oder Ableitung ein strukturierter Sicherheitskonzeptgraph 26 erzeugt. Dieser strukturierte Sicherheitskonzeptgraph 26 weist eine im Vergleich zu dem Sicherheitskonzeptgraphen 20 feinere oder detailliertere Struktur mit hier schematisch angedeuteten Teilfunktionen 28 auf. Durch diese Struktur, also letztlich die Teilfunktionen 28, sind hier insbesondere die Softwaremodule 16, also die Knoten des Abhängigkeitsgraphen 14 - ebenfalls in maschinenlesbarer Form - in dem strukturierten Sicherheitskonzeptgraphen 26 enthalten oder repräsentiert. Dazu können beispielsweise aus einzelnen Elementen oder Einträgen des Sicherheitsdokuments 12 oder des Sicherheitskonzeptgraphen 20 die Teilfunktionen 28, also individuelle Knoten oder Sub-Knoten des strukturierten Sicherheitskonzeptgraphen 26 gebildet oder erzeugt werden. Die Teilfunktionen 28 können also zumindest hinsichtlich ihres Inhaltes oder ihrer Bedeutung den Softwaremodulen 16, also den Knoten des Abhängigkeitsgraphen 14 entsprechen.
Damit weisen der strukturierte Sicherheitskonzeptgraph 26 und der Abhängigkeitsgraph 14 zumindest im Wesentlichen die gleichen Strukturen, zumindest aber aufeinander abbildbare Strukturen auf. Durch Kombination des Abhängigkeitsgraphen 14 und des strukturierten Sicherheitskonzeptgraphen 26 wird dann ein angereicherter Graph 30 erzeugt. Der angereicherte Graph 30 weist also ebenfalls miteinander verbundene Knoten auf und entspricht in seiner Struktur dem Abhängigkeitsgraphen 14. Dies ist hier schematisch durch beispielhafte Kennzeichnung eines Knotens als Softwaremodule 16 und einer Verbindung als Kante 18 angedeutet. Zusätzlich weist der angereicherter Graph 30 Datenfelder für beziehungsweise mit Annotationen 32 an seinen Knoten und deren Verbindungen auf. Diese Annotationen 32 sind aus dem Sicherheitskonzept 10 abgeleitet oder entnommen und enthalten darauf basierende Regeln an, die angeben wie ein jeweiliger aktueller Sicherheitsstatus der Softwaremodule 16 entlang der Struktur des angereicherten Graphen 30 miteinander zu kombinieren sind. Die Knoten des angereicherten Graphen 30 können zusätzlich oder alternativ einen jeweiligen vorgegebenen Ziel-Sicherheitsstatus, also beispielsweise ein vorgegebenes Ziel-ASIL, enthalten oder angeben.
In einem nächsten Schritt wird in dem angereicherten Graphen 30 für dessen Blätter 34, also dessen Endknoten, deren jeweiliger aktueller Sicherheitsstatus ergänzt. Dies kann manuell, automatisch oder teilautomatisch erfolgen. Die Sicherheitsstatus der Blätter 34 können beispielsweise ebenfalls in die entsprechenden Annotationen 32 beziehungsweise in die entsprechenden Datenfelder aufgenommen werden. Vorliegend wird der Sicherheitsstatus durch ein jeweiliges Sicherheitsattribut in Form eines jeweiligen aktuellen ASIL beschrieben, was hier durch entsprechende Buchstaben A, B, D beispielhaft angedeutet ist.
Auf Basis des derart angereicherten Graphen 30 können dann automatische Auswertungen durchgeführt werden, beispielsweise mittels eines vorgegebenen Algorithmus, der den angereicherten Graphen 30 ausgehend von dessen Blättern 34 durchläuft. Ein solcher Algorithmus kann dann beispielsweise automatisiert die in dem angereicherten Graphen 30 angegebenen aktuellen Sicherheitsstatus gemäß den Annotationen 32 entlang der Struktur des angereicherten Graphen 30 miteinander kombinieren. Daraus ergibt sich beispielsweise ein erster Ergebnisgraph 36, in dem aus den Sicherheitsstatus der Blätter 34 und den Annotationen 32 automatisch die aktuellen Sicherheitsstatus von inneren Knoten 38 ermittelt und angegeben sind. Die Sicherheitsstatus der inneren Knoten 38 müssen hier also nicht vorgegeben sein, sondern können automatisch durch entsprechende Aggregation oder Kombination bestimmt werden. Dies ist hier dadurch repräsentiert, dass die derart ermittelten Sicherheitsstatus durch entsprechende unterstrichene Buchstaben (A) repräsentiert sind.
Weiter kann ein zweiter Ergebnisgraph 40 automatisiert erzeugt werden. Dazu kann basierend auf dem ersten Ergebnisgraphen 36 eine Rücktransformation von dem Implementierung-, Code- oder Software-Level des Abhängigkeitsgraphen 14 beziehungsweise der Softwaremodule 16 zu dem abstrakteren oder höheren Level des Sicherheitskonzeptgraphen 20 durchgeführt werden. Dazu können beispielsweise die Softwaremodule 16 jeweils eines Zweigs oder Astes oder Sub-Graphen des angereicherten Graphen 30 einschließlich ihrer jeweiligen Sicherheitsstatus zu den logischen Komponenten 22 aggregiert werden. Diese Rücktransformation stellt mit anderen Worten einen der genannten architekturbasierten Deduktion zum Erzeugen des strukturierten Sicherheitskonzeptgraphen 26 entgegengesetzten Prozess dar. Um dabei die Konsistenz mit dem ursprünglichen technischen Sicherheitskonzept 10 beziehungsweise dem Sicherheitskonzeptgraphen 20 zu wahren, kann in den Annotationen 32 beispielsweise angegeben sein, aus welcher der logischen Komponenten 22 die jeweilige Annotation 32 abgeleitet ist oder welcher der logischen Komponenten 22 die jeweilige Annotation 32 beziehungsweise ein damit annotiertes Element des angereicherten Graphen 30 zugeordnet oder zuzuordnen ist.
Auf diese Weise können also auch auf dem abstrakteren oder höheren Level technischer Funktionen, wie sie in dem Sicherheitskonzeptgraphen 20 beziehungsweise dem zweiten Ergebnisgraphen 40 durch die logischen Komponenten 22 repräsentiert sind, ein jeweiliger aktueller Sicherheitsstatus automatisiert bestimmt und ausgegeben werden.
Für die Automatisierung der hier beschriebenen Abläufe kann eine entsprechende formalisierte logische Sprache, beispielsweise Prolog oder dergleichen, verwendet werden, um die Regeln für die Kombination oder Aggregation von Sicherheitsstatus, insbesondere ASILs, zu definieren beziehungsweise derartige Kombinationen oder Aggregation durchzuführen, also aus wenigstens zwei aktuellen Sicherheitsstatus den jeweiligen resultierenden Sicherheitsstatus eines hierarchisch übergeordneten Elements zu bestimmen. Durch diese Sprache kann also eine Transformation von Sicherheitsstatus oder Sicherheitslevels formalisiert sein.
Durch die Kombination einer solchen Sprache, welche die genannten Sicherheitsstatus, Regeln, Annotationen 32 und dergleichen maschinenlesbar angeben kann, und den angereicherten Graphen 30 können insgesamt Sicherheitsevaluierungen auch sehr großer und komplexer Software- oder Entwicklungsprojekte automatisiert, besonders zuverlässig sowie auf einfache Weise besonders häufig ermöglicht beziehungsweise durchgeführt werden.
Zusammenfassend ist vorliegend beschrieben, wie die Architektur eines, insbesondere großen, Softwareprojekts, wie etwa einem Projekt zur Entwicklung und Implementierung des autonomen Fahrens, also autonomer Fahrfunktionen für ein Kraftfahrzeug, direkt auf ein heutiges modernes Software-Build-System angewendet werden kann. Dabei können mehrere Quellcodedateien zu Modulen beziehungsweise Knoten gruppiert werden. Diese Module beziehungsweise Knoten können dann zu einem Graphen arrangiert werden, wodurch sich inhärent ein sogenannter build target, also ein Entwicklungsziel, als Wurzelknoten des Graphen ergibt. Dieses Entwicklungsziel kann etwa eine ausführbare Gesamtsoftware, beispielsweise für ein eingebettetes Steuergerät oder dergleichen, sein.
Das Software-Build-System kann Definitionen enthalten, die angeben, wie verschiedene Elemente, Komponenten oder Module aufgebaut sind und/oder miteinander in Beziehung stehen, um die komplexe Gesamtsoftware zu erzeugen oder zu bilden. Ein entsprechender Abhängigkeits- oder Architekturgraph kann aber ebenso beispielsweise durch parsen tatsächlich implementierter Abhängigkeit in den Quellcodedateien, beispielsweise C++ Quellcodedateien des Softwareprojekts, abgeleitet oder erzeugt werden, insbesondere automatisch oder teilautomatisch.
Die Sicherheitsattribute, hier also die ASIL, werden in einem einmaligen Initialisierungsvorgang für die Blätter 34 vorgegeben, beispielsweise durch einen jeweiligen Entwickler oder ein jeweiliges Entwicklerteam für das jeweilige Blatt 34 oder das entsprechende Softwaremodul 16. Alternativ oder bei fehlender Vorgabe kann ein vorgegebener Standardwert verwendet werden, beispielsweise ASIL QM. Ziel ist es dann, darauf basierend die Sicherheitsattribute der übrigen Knoten beziehungsweise Module automatisiert zu bestimmen. Fehlt für eines der Blätter 34 das Sicherheitsattribut, kann die automatische Bestimmung durch einen entsprechenden Algorithmus verweigert werden, beispielsweise unter Ausgabe einer entsprechenden Fehlermeldung zu dem fehlenden Input.
Alle Knoten können ein jeweiliges Datenfeld für ein entsprechendes Sicherheitsattribut, hier also das jeweilige ASIL, aufweisen. In diese Datenfelder können die vorgegebenen oder automatisch bestimmten Sicherheitsattribute beziehungsweise deren Werte geschrieben werden. Dies ist hier durch die Annotationen 34 angedeutet.
Die vorgegebenen Sicherheitsattribute der Blätter 34 bilden einen ersten Input für einen vorgegebenen Algorithmus zum Bestimmen der Sicherheitsattribute der von den Blättern 34 verschiedenen übrigen Knoten. Ausgehend von den Blättern 34 und deren Sicherheitsattributen kann der Algorithmus dann die Sicherheitsattribute der übrigen Knoten bis hin zu einem obersten Knoten oder Wurzelknoten berechnen, indem iterativ die Sicherheitsattribute hierarchisch untergeordneter Knoten zum Sicherheitsattribut des jeweiligen hierarchisch direkt, also unmittelbar übergeordneten Knoten aggregiert, also kombiniert werden.
Für diese Aggregierung oder Kombinierung kann der Algorithmus als zweiten Input entsprechende vorgegebene Aggregations- oder Kombinationsregeln verwenden. Diese Regeln definieren, wie die Sicherheitsattribute von spezifischen untergeordneten Knoten zu spezifischen diesen übergeordneten Knoten aggregiert oder kombiniert werden sollen. Die Regeln können hier für jeden hierarchisch übergeordneten Knoten für dessen Beziehung oder Relation zu seinen hierarchisch, insbesondere direkt, untergeordneten Knoten vorgegeben sein. Auf diese Weise kann automatisch der Sicherheitsstatus, hier also das resultierende ASIL für die Gesamtsoftware, also für das gesamte Software- oder Entwicklungsprojekt bestimmt oder berechnet werden.
Die Aggregations- oder Kombinationsregeln können hier durch die oder basierend auf den ASIL Dekompositionsregeln gemäß ISO 26262 sowie gegebenenfalls weitere Regeln aus der Sicherheitsdomäne gegeben sein.
Als, gegebenenfalls optionalen, dritten Input kann der Algorithmus Sicherheitsanforderungen beziehungsweise Sicherheitszustände verwenden. Diese geben spezifische sicherheitsrelevante Anforderungen an und geben in dem jeweiligen Sicherheitszustand an, ob die Anforderungen erfüllt sind. Ein Beispiel für derartige Sicherheitsanforderungen ist die Störungsfreiheit (englisch: freedom from interference) für zwei oder mehr Knoten oder Softwaremodule 16. Der zugehörige Sicherheitszustand gibt dann an, ob die Störungsfreiheit mit oder in der aktuellen Implementierung gegeben ist oder nicht.
Die Aggregations- oder Kombinationsregeln und/oder die Sicherheitsanforderungen können - direkt oder indirekt - aus dem technischen Sicherheitskonzept 10 beziehungsweise aus dem Sicherheitsdokument 12 oder dem Sicherheitskonzeptgraph 20 ermittelt oder abgeleitet werden. Dies kann manuell erfolgen. Bevorzugt kann das Sicherheitskonzept 10 oder das Sicherheitsdokument 12 in ein algorithmisch oder maschinenlesbares Format transformiert werden und/oder in einer maschinenlesbaren Modellierungssprache modelliert sein. Daraus können die Aggregations- oder Kombinationsregeln und/oder die Sicherheitsanforderungen dann abgeleitet und mit den Knoten oder Softwaremodulen 16 verlinkt oder diesen zugeordnet, also auf diese abgebildet werden.
Die Aggregations- oder Kombinationsregeln, die Sicherheitsanforderungen und/oder die vorgegebenen, also nicht durch den Algorithmus berechneten, Sicherheitsattribute können beispielsweise in einem jeweiligen Quellcode-Verwaltungssystem für das Softwareprojekt gespeichert werden. Die algorithmisch berechneten Sicherheitsattribute können hingegen von einer solchen Speicherung ausgeschlossen sein und stattdessen stets bei Bedarf neuberechnet werden.
Bei der algorithmischen Bestimmung der Sicherheitsattribute bleiben die bei jeder Einzelberechnung als Ausgangs- oder Eingangswerte verwendeten Sicherheitsattribute unverändert. Die Sicherheitsattribute werden also nur entlang der Struktur des Graphen in einer Richtung von den Blättern 34 zu dem Wurzelknoten berechnet und geschrieben oder überschrieben. Auf diese Weise führt ein Fehler in einem weniger sicherheitskritischen Knoten oder Softwaremodul 16 nicht zu einem Fehler in einem sicherheitskritischeren Knoten oder Softwaremodul 16.
Da die hier vorgeschlagene automatische Bestimmung oder Berechnung der Sicherheitsattribute das Skelett oder Grundgerüst eines existierenden Software-Build-Systems nutzen kann, kann sie besonders schnell und zuverlässig ausgeführt werden. Die Bestimmung der Sicherheitsattribute kann beispielsweise als Teil eines kontinuierlichen Integrationssystems erfolgen, das zu jedem beliebigen Zeitpunkt den aktuellen Sicherheitsstatus des build targets ausgeben kann.
Durch Anwendung entsprechender vorgegebener Graph-Auswertungs-Algorithmen können automatisiert weitere wertvolle Informationen oder Angaben gewonnen werden, beispielsweise bezüglich Knoten oder Softwaremodulen 16, die auf einem jeweils aktuell für den Sicherheitsstatus besonders relevanten oder kritischen Pfad des Graphen liegen. Dadurch können Entwicklungsressourcen auf spezifische Knoten oder Softwaremodule 16 fokussiert werden, um einen bestimmten Sicherheitsstatus, beispielsweise ein bestimmtes ASIL, möglichst schnell und möglichst effizient zu erreichen.
Bezugszeichenliste

10: Sicherheitskonzept
12: Sicherheitsdokument
14: Abhängigkeitsgraph
16: Softwaremodule
18: Kanten
20: Sicherheitskonzeptgraph
22: logische Komponenten
24: Relationen
26: strukturierter Sicherheitskonzeptgraph
28: Teilfunktionen
30: angereicherter Graph
32: Annotationen
34: Blätter
36: erster Ergebnisgraph
38: innere Knoten
40: zweiter Ergebnisgraph

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102017204212 A1 [0004]
US 2020/0065234 A1 [0005]

Claims

Verfahren zum Ermöglichen einer Evaluierung eines aktuellen Software-Sicherheitsstatus, in dem - für ein vorgegebenes Softwaresystem, das mehrere Softwareteile (16) umfasst, ein gerichteter Graph (30) erzeugt wird, dessen Struktur Abhängigkeiten zwischen den Softwareteilen (16) repräsentiert, wobei jeder Softwareteil (16) einem Knoten (34, 38) des Graphen (30) zugeordnet wird und jeder Knoten (34, 38) ein Datenfeld (32) für ein Sicherheitsattribut, das den aktuellen Sicherheitsstatus des dem jeweiligen Knoten (34, 38) zugeordneten Softwareteils (16) angibt, aufweist, - für die Blätter (34) des Graphen (30) deren jeweiliges Sicherheitsattribut vorgegeben wird, - Regeln (32) vorgegeben werden, die angeben, wie für die übrigen Knoten (38) zum Bestimmen von deren jeweiligem Sicherheitsattribut die Sicherheitsattribute der jeweils hierarchisch untergeordneten Knoten (34, 38) entlang der Struktur des Graphen (30) miteinander zu kombinieren sind.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Regeln (32) zum Kombinieren der Sicherheitsattribute in einer regeldefinierenden logischen Programmiersprache angegeben sind.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Sicherheitsattribute ein jeweiliges standardisiertes Sicherheitslevel, insbesondere ein ASIL (A, B, D), angeben und die Regeln (32) durch entsprechende vorgegebene Dekompositionsregeln für die Sicherheitslevel bestimmt werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Graph (30) basierend auf einem Abhängigkeitsgraphen (14) erstellt wird, der automatisch durch ein Software-Erstellungswerkzeug bereitgestellt wird, oder aus dem Quelltext des Softwaresystems, insbesondere aus dessen Header-Dateien, generiert wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als Parameter für wenigstens eine der vorgegebenen Regeln (32) ein jeweiliger aktueller Erfüllungszustand wenigstens einer vorgegebenen Sicherheitsanforderung für wenigstens einen der Softwareteile (16) und/oder der Knoten (34, 38) vorgegeben und zum Bestimmen der Sicherheitsattribute der übrigen Knoten (38) berücksichtigt wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zumindest die Regeln (32) aus einem in maschinenlesbarer Form bereitgestellten technischen Sicherheitskonzept (10, 12, 20) abgeleitet werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Sicherheitsattribute zumindest eines Teils der übrigen Knoten (38) vorgegeben werden können und diese übrigen Knoten (38) dann ein Signaturdatenfeld (32) zum Identifizieren einer jeweiligen Person, die das jeweilige Sicherheitsattribut vorgegeben hat, aufweisen, wobei entsprechende vorgegebene Sicherheitsattribute beim Bestimmen der Sicherheitsattribute automatisch berücksichtigt werden.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für die Softwareteile (16) und/oder für Knoten (34, 38) des Graphen (30) ein jeweiliges zu erreichendes Ziel-Sicherheitsattribut, insbesondere ein Ziel-ASIL (A, B; D), vorgegeben ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass durch Auswerten der aktuellen Sicherheitsattribute der Knoten (34, 38) des Graphen (30) unter Berücksichtigung der vorgegebenen Regeln (32) und der Struktur des Graphen (30) mittels eines vorgegebenen Algorithmus automatisch ein minimaler Satz von Knoten (34, 38) bestimmt wird, für die eine Verbesserung ihres Sicherheitsattributs zu einer Verbesserung des Sicherheitsattributs eines Wurzelknotens des Graphen und/oder zu einer Verbesserung des Sicherheitsstatus des Softwaresystems insgesamt führen würde.
Datenverarbeitungseinrichtung, umfassend einen Prozessor und einen damit verbundenen Datenspeicher, die dazu eingerichtet ist, basierend auf einem Verfahren nach einem der vorhergehenden Ansprüche automatisch einen Software-Sicherheitsstatus für ein vorgegebenes Softwaresystem zu bestimmen.