Softwaresicherheit, Teil 3 Zukunftssicherheit von Embedded-Software

Peter Siwon und Alexander Sedlak *

Anbieter zum Thema

Im dritten Teil unserer Serie geht es um den etwas schwieriger zu definierenden Begriff der Zukunftssicherheit. Dabei soll es nicht ausschließlich darum gehen, dass künftige Anforderungen der Betriebs- und Angriffssicherheit, der Funktionalität, des Designs und der Standards auch in Zukunft wettbewerbsfähig erfolgen

Open-Source-Codes: Viele Entwickler arbeiten an einem Softwaresystem. Doch wem gehört der Code?
Open-Source-Codes: Viele Entwickler arbeiten an einem Softwaresystem. Doch wem gehört der Code?
(Foto: Gerd Altmann, pixelio.de)

Der Gedanke liegt nahe, dass es hellseherischer Fähigkeiten bedarf, um heute schon sagen zu können, welchen Gefahren und Herausforderungen die aktuelle Embedded Software in der Zukunft ausgesetzt sein wird. Doch zum Glück gibt es auch ganz diesseitige Methoden und Hilfsmittel, die uns, konsequent angewendet, diesem Ziel näher bringen können.

Ein prominentes Beispiel zeigt, wie wichtig die Zukunftssicherheit sein kann: 1977 starteten von Cape Canaveral 2 Trägerraketen, beladen mit den Voyager Raumsonden. Sie hatten die Aufgabe, verschiedene Planeten unseres Sonnensystems zu erkunden. Die geschätzte Projektlaufzeit betrug rund 5 Jahre. Alles musste über diese Lebensdauer störungsfrei funktionieren. Das Voyager-Programm funktioniert viel besser als erwartet.

Bis heute funken die Sonden ihre Signale, rund 30 Jahre länger als geplant. Die verantwortlichen Techniker haben ihre Sache offensichtlich gut gemacht. Das System hatte allerdings einen großen Vorteil: Es blieb über seine Lebensdauer unverändert.

Wie es allerdings ausgehen kann, wenn Software häufigen Änderungen unterworfen ist, zeigte sich beim Smartphone-Betriebssystem Symbian. Es hatte einige Jahre sehr gute Dienste geleistet, doch nach und nach begann es, instabil zu werden. Auch bei kleinen Änderungen wurde immer schwieriger, die Software wieder zu stabilisieren.

Heute verschlänge die Weiterentwicklung so große Ressourcen, dass mit neuen Versionen nicht mehr zu rechnen ist. Diese veränderungsbedingte Fragilität nennt man Softwareerosion. Softwareerosion gehört damit zu den größten Bedrohungen für die schnellen Innovationzyklen in vielen Branchen, wie Thomas Eisenbarth von der Firma Axivion und Prof. Dr. Koschke betonen.

Beide befassen sich seit mehreren Jahren mit gezielten Maßnahmen gegen Softwareerosion. Sie sehen in einem besseren Problembewusstsein und in automatisierten Erosionstests in Verbindung mit konsequenten Gegenmaßnahmen wichtige Voraussetzungen. Rudolf Frommknecht, Squoring, ergänzt, welche Bedeutung Ausbildung, Prozessgestaltung und Toolauswahl haben.

Softwaresicherheit näher betrachtet

In insgesamt drei Teilen haben wir Ihnen das Thema der Softwaresicherheit versucht, näher zu bringen. Dazu haben wir Aussagen von Referenten aus dem ESE Kongress 2011 zusammengefasst. Im ersten Teil ging es um das Thema der Betriebssicherheit und das Softwarequalität erlernbar ist. Im zweiten Teil stellten wir die Zugriffs- und Angriffssicherheit in den Mittelpunkt. Hier zeigte sich, dass vor allem der menschliche Faktor eine Schwachstelle darstellt. Schließlich im aktuell vorliegenden dritten Teil beleuchten wie die Zukunftsfähigkeit von Software und welche Vorteile und Risiken Open-Source bietet.

Softwaresicherheit, Teil 1:Die drei Gesichter der Sicherheit von Software-Systemen

Softwaresicherheit, Teil 2: Die drei Gesichter der Sicherheit

Wie sich die Qualität von Software beurteilen lässt

Heute sind die Herausforderungen an Softwareentwickler für Embedded-Systeme, um Zukunftssicherheit bei ihren Produkten hinsichtlich Softwareerosion und auch allgemein zu gewährleisten, bekannter als noch vor wenigen Jahren. Generell gilt der Grundsatz: Keep it simple.

Die Vermeidung undurchsichtiger Konstrukte und die Wahl eines Softwarecodex, der weitgehend selbsterklärende und überschaubare Softwareelemente fordert, ist ein guter Einstieg in diese Zukunftssicherung. Jede Software, die aus der Hand eines Programmierers geflossen ist, kann gewissermaßen in ihrem "so sein, wie sie ist" beurteilt werden. Dieses "so sein" wird landläufig mit dem Begriff der Qualität bezeichnet.

Qualitätsmodelle helfen, spezifische Qualitätskriterien von Produkten zu beurteilen. Klaus Wissing von Squoring erklärte auf dem Embedded Software Engineering Kongress 2011, dass bei der Softwareentwicklung immer mehr Personen mit ganz unterschiedlichen Rollen und Blickwinkeln beteiligt sind. Die Aufgaben innerhalb der Prozesse sind einerseits hochgradig vernetzt, müssen andererseits auch gegeneinander abgegrenzt werden.

Die Vielfalt der sich daraus ergebenden Projektanforderungen zu beherrschen, ist die große Herausforderung. Jeder Projektbeteiligte muss dazu einen realistischen Einblick in den Projektfortschritt und die Softwarequalität erhalten, der seinem Informationsbedürfnis und seinem Kenntnishorizont entspricht. Idealerweise wird diese Information per Knopfdruck auf Basis definierter Qualitätsmodelle automatisch ermittelt und visualisiert.

Die große Kunst besteht nun darin, geeignete Qualitätsmodelle zu erstellen und diese auch an veränderte Bedingungen anzupassen. Bekannte und verbreitete Standards, Normen und Metriken dienen als Grundlage für solche Qualitäts- und Bewertungsmodelle. Der konkrete Fall ist eingehend zu betrachten und angepasste Tools und Maßnahmen sind einzusetzen. In Bezug auf die Beurteilung von Zukunftssicherheit würde das bedeuten, dass eine Software und der damit verbundene Prozess anhand spezifischer Kriterien, wie der Updatefähigkeit, der Wirksamkeit des Change-Managements oder der Stabilität, nach Änderungen geprüft werden.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Artikelfiles und Artikellinks

(ID:34878320)