Sicherheit und Software-Änderungsmanagement verbinden

Wenn wir Software erstellen, die super sicher sein muss, wie Systeme für Flugzeuge oder medizinische Geräte, müssen wir vorsichtig sein. Wenn diese Systeme versagen, können Menschen verletzt werden oder die Umwelt geschädigt werden. Also müssen wir ständig überprüfen, dass sie sicher sind.

Eine Möglichkeit, zu zeigen, dass wir an Sicherheit gedacht haben, ist etwas, das man Safety Assurance Case (SAC) nennt. Ein SAC ist basically eine Gruppe von Gründen und Beweisen, die sagen, dass das System sicher zu benutzen ist. Es zerlegt Sicherheitsansprüche in kleinere Teile, die durch Beweise wie Tests und Simulationen unterstützt werden. Das hilft jedem, zu verstehen, wie Entscheidungen über die Sicherheit getroffen wurden.

Diese Sicherheitsfälle zu erstellen und auf dem neuesten Stand zu halten ist nicht einfach, besonders wenn sich die Software ändert. Das liegt daran, dass es manchmal eine Lücke gibt zwischen dem, was in Bezug auf Sicherheit und dem, was in der Software gemacht wird. Leute, die sich auf Sicherheit konzentrieren, wissen vielleicht nicht genug über die Software selbst und umgekehrt. Wegen dieser Disconnect kann es schwierig sein, die Sicherheitsargumente zu aktualisieren, wenn sich etwas in der Software ändert.

In vielen Fällen haben Sicherheitsexperten darauf hingewiesen, dass es keine guten Möglichkeiten gibt, Änderungen an SACs effektiv zu managen. Wenn also etwas in der Software sich ändert, kann es knifflig sein, für Sicherheitsexperten herauszufinden, wie es die Sicherheit beeinflusst.

Sie wollen ein paar Dinge wissen, wenn sich die Software ändert:

1. Warum hat sich die Software geändert?
2. Welches Risiko versucht diese Änderung zu beheben?
3. Wie könnte diese Änderung die Sicherheit beeinflussen?

Um die Sache leichter zu machen, können wir die Sicherheitsargumente direkt mit den Softwareänderungen verbinden. Das bedeutet, wir müssen wichtige Teile der Software mit den Sicherheitsgründen verknüpfen und alle Änderungen im Blick behalten. So wissen die Leute, die an der Sicherheit arbeiten, wenn sich etwas in der Software ändert und wie das die Sicherheit beeinträchtigen könnte.

#Verbindung zwischen Software und Sicherheit

Um dieses Problem anzugehen, schlagen wir eine Methode vor, um Softwareänderungen mit Sicherheitsargumenten auf organisierte Weise zu verbinden. Mit einer Technik namens Safety Artifact Forest Analysis (SAFA) können wir automatisch Änderungen in der Software erkennen. Es vergleicht zwei Versionen der Software und erstellt eine visuelle Darstellung dessen, was sich geändert hat. Mit dieser visuellen Darstellung können Sicherheitsteams genau sehen, was hinzugefügt, entfernt oder modifiziert wurde und wie es ihre Sicherheitsargumente beeinflusst.

Wenn sich die Software ändert, hilft unsere Methode auch dabei, die Gründe für diese Änderungen festzuhalten. Die Leute, die an der Software arbeiten, wie Entwickler, können ihre Gründe und andere wichtige Details zu jeder Änderung angeben. Das hilft den Sicherheitsteams zu verstehen, ob die Änderungen gut oder schlecht für die Sicherheit sind.

Zum Beispiel, wenn wir ein System für Drohnen entwerfen, die in Notfällen wie Suche und Rettung eingesetzt werden, ist eine wichtige Anforderung, dass die Drohne wissen muss, wo sie fliegen darf und wo nicht. Das ist entscheidend, denn wenn eine Drohne in einen eingeschränkten Luftraum fliegt, kann das Unfälle verursachen.

Eine Anforderung für die Drohnen war, dass sie während des Flugs ständig nach Luftrauminformationen suchen müssen. In einer neueren Version der Software wurde dies geändert, sodass nur beim Planen neuer Flugrouten nach dem Luftraum geschaut wird. Unser System kann diese Änderung klar anzeigen und den Sicherheitsexperten helfen, zu beurteilen, ob das immer noch sicher ist.

#Alle Teile verknüpfen

Bei der Entwicklung sicherer Systeme fangen wir damit an, potenzielle Gefahren zu identifizieren. Das nennt man eine vorläufige Gefahrenanalyse (PHA). Von dort aus erstellen wir Fault Trees (FT) oder eine Failure Mode and Effects Criticality Analysis (FMECA), um diese Risiken besser zu verstehen. Während unser Fokus hauptsächlich auf Fault Trees liegt, können die gleichen Ideen auch auf FMECA angewendet werden.

Fault Trees helfen uns, Risiken in kleinere Teile zu zerlegen und aufzuzeigen, wie unterschiedliche Ereignisse Sicherheitsprobleme verursachen könnten. Es geht darum, Risiken zu verstehen und zu managen.

In unserer Methode stellen wir sicher, dass es eine direkte Verbindung zwischen einem Fault Tree und seinen relevanten Teilen im Safety Assurance Case gibt. Diese Verbindung hilft uns, die Sicherheitsargumente und das Design des Systems zusammenzubringen.

Indem wir diese Verbindungen klar und aktuell halten, wird jede Änderung im System Hinweise durch die verknüpften Sicherheitsargumente senden. So können wir, wenn sich etwas in der Software ändert, schnell beurteilen, wie sich das auf die Sicherheit auswirkt.

#Bedeutung der Erfassung von Gründen

Um wirklich zu verstehen, wie Änderungen die Sicherheit beeinflussen, müssen wir die Gründe dafür festhalten. Wenn ein Entwickler etwas im Code ändert, muss er angeben, warum er diese Änderung vorgenommen hat. Dazu gehört, welche Alternativen sie in Betracht gezogen haben und was zu ihrer endgültigen Entscheidung geführt hat.

Zum Beispiel, wenn eine Sicherheitsanforderung für eine Drohne sagt, dass sie Echtzeit-Luftraumdaten abrufen soll, könnten Änderungen, wie dies geschieht, die Sicherheit beeinflussen. Es ist entscheidend, einen klaren Nachweis darüber zu führen, warum und wie diese Anforderungen geändert werden. Es liefert den Kontext, den Sicherheitsanalysten brauchen, um zu bewerten, ob das neue Design immer noch sicher ist oder ob zusätzliche Vorsichtsmassnahmen erforderlich sind.

#Herausforderungen in der Zukunft

Es gibt noch viele Herausforderungen, die angegangen werden müssen, wenn es darum geht, Sicherheit und Softwareentwicklung zu verknüpfen. Ein wichtiger Bereich ist das Wissensmanagement. Was müssen Sicherheitsanalysten wissen? Wie können wir diese Informationen effektiv sammeln? Das sind entscheidende Fragen, die beantwortet werden müssen.

Eine weitere Herausforderung ist die intelligente Analyse von Änderungen. Softwareänderungen können auf verschiedenen Ebenen auftreten. Wir wollen zwischen harmlosen Änderungen und solchen unterscheiden, die riskant sein könnten. Für zukünftige Ansätze hoffen wir, intelligentere Systeme zu nutzen, um Änderungen zu analysieren und umsetzbare Schritte vorzuschlagen, wenn die Sicherheit gefährdet sein könnte.

Schliesslich müssen wir die Werkzeuge, die in diesem Prozess verwendet werden, verbessern. Die aktuellen Systeme bieten oft nicht die Unterstützung, die benötigt wird, um die Verbindung zwischen Sicherheitsansprüchen und Softwareänderungen zu verwalten. Es ist entscheidend, benutzerfreundliche Tools zu entwickeln, die helfen, diese Verbindung aufrechtzuerhalten, während es für Analysten und Entwickler einfacher wird, ihre Arbeit zu erledigen.

#Fazit

Zusammengefasst ist die Aufrechterhaltung der Sicherheit in der Softwareentwicklung entscheidend, besonders für Systeme, bei denen Leben auf dem Spiel stehen könnten. Die Verknüpfung der Punkte zwischen Sicherheitsanforderungen und Softwareänderungen ist entscheidend, um sicherzustellen, dass die Sicherheit während des gesamten Entwicklungsprozesses im Vordergrund bleibt.

Indem wir klare Verbindungen zwischen Änderungen in Software und Sicherheitsargumenten schaffen und die Gründe hinter diesen Änderungen festhalten, können wir verbessern, wie wir Sicherheit in der Softwareentwicklung managen. Wenn wir nach vorne schauen, wird es wichtig sein, die Herausforderungen, denen wir gegenüberstehen, anzugehen, um sicherere Systeme zu schaffen, die sich an neue Änderungen anpassen können und dabei alle sicher bleiben.