Die meisten von uns haben wohl schon Erfahrungen mit Computerfehlern gemacht: Sei es, daß eine Rechnung oder ein Behördenbescheid an den falschen Adressaten gerichtet war oder daß eine mysteriöse Panne im Personalcomputer die Arbeit eines ganzen Tages zerstörte. Solche Probleme, die häufig durch einen Fehler in der Software – im englischen Fachjargon auch bug genannt – hervorgerufen werden, mögen zwar lästig sein, sind aber harmlos im Vergleich zu den möglichen Folgen entsprechender Störungen in Systemen, die über Leben und Tod entscheiden können. So brach beispielsweise das Telephonnetz in den Vereinigten Staaten aufgrund eines Programmfehlers mehrmals weiträumig zusammen. Möglicherweise war ein ähnliches Problem schuld daran, daß im Golf-Krieg das Patriot-Abwehrsystem jene irakische Scud-Rakete nicht abzufangen vermochte, die 28 amerikanische Soldaten das Leben kostete (Bild 1).

Ingenieure verstehen es mittlerweile sehr gut, bei mechanischen Geräten Mängel zu vermeiden oder zu beheben. Selbst wenn dort Konstruktionsfehler auftreten sollten, ist doch die Zuverlässigkeit aufgrund des vergleichsweise einfachen Aufbaus solcher Geräte weniger heikel als bei computerisierten Systemen. Je umfangreicher und komplexer nämlich ein Computerprogramm ist, desto wahrscheinlicher bleiben Fehler im Entwurf unentdeckt und machen sich erst bei der späteren Anwendung bemerkbar. Daß Softwarefehler im allgemeinen viel heimtückischer sind als mechanische Störungen, gilt übrigens keineswegs nur für exotische militärische Systeme, Flugzeuge oder Flugleitsysteme; denn komplexe Software spielt mittlerweile auch in eher alltäglichen Bereichen eine kritische Rolle – etwa bei der Allrad-Lenkung oder bei Antiblockiersystemen (ABS) von Autos. Es könnte sogar durchaus sein, daß in kritischen Systemen – etwa in den Sicherheitseinrichtungen einer chemischen Anlage, die giftige oder explosive Substanzen produziert – das angemessene Sicherheitsniveau nur gewährleistet werden kann, indem man die Abhängigkeit von der Software begrenzt.

Ursache von Softwarefehlern

Zumindest theoretisch sind Softwarefehler vermeidbar. Da Computerprogramme im Unterschied zu Werkstoffen und Maschinen keinem Verschleiß unterliegen, sind alle Programmier- und Konzeptionsfehler bereits ab dem Zeitpunkt der Installation auf einem Rechner vorhanden. Beim Austesten müßten sich diese Fehler im Prinzip erkennen und ein für alle Male entfernen lassen. Zudem sollten Programmierer eigentlich mit mathematischen Verfahren das korrekte Funktionieren nachweisen können.

Dennoch bleibt das Ziel einer perfekten Software Illusion. Denn trotz strenger und systematischer Testverfahren enthalten die meisten großen Programme bei ihrer Auslieferung noch einige unentdeckte Fehler. Der Grund ist die Komplexität des Quellcodes. Ein Programm von nur wenigen hundert Zeilen Umfang kann bereits Dutzende von Entscheidungsfunktionen enthalten und dadurch Tausende von alternativen Ausführungspfaden ermöglichen. (Programme für relativ kritische Anwendungen können wenige Dutzend, aber auch einige Millionen Zeilen umfassen.) Falsche Programmentscheidungen können als Folge spezieller Eingaben entstehen, wenn diese während der Testphase – wo Fehler noch hätten korrigiert werden können – nicht ausprobiert worden sind. Möglicherweise wurde auch die Situation, die diese Eingabedaten bewirkt, beim Entwurf falsch eingeschätzt oder gar völlig übersehen: Der Entwickler programmierte dann „korrekt“ die falsche Reaktion oder zog die Situation überhaupt nicht in Betracht. Derartige Fehler sind am schwierigsten auszumerzen.

Auch ändern sich häufig im Verlauf von Systementwicklungen die Spezifikationen, weil man in der Zwischenzeit den geplanten Einsatzzweck des Systems modifiziert oder die zu bearbeitende Aufgabe besser verstanden hat. Solche Veränderungen können sich auf alle Teile des Systems auswirken, so daß der vorherige Entwurf überholt ist. Des weiteren kann die tatsächliche Verwendung von dem eigentlich geplanten Einsatzmodus abweichen. So hat man das Versagen einiger Patriots beim Abfangen von Scud-Raketen auf die Akkumulation von Ungenauigkeiten der internen Uhr in einem Rechner zurückgeführt. Dennoch erfüllte er seine Spezifikationen: Beim Systementwurf war man davon ausgegangen, daß der Computer häufig genug ab- und wieder eingeschaltet würde, so daß der akkumulierte Fehler niemals gefährlich werden könnte. Da man das System aber nicht wie vorgesehen betrieb, wurde aus einer kleinen Ungenauigkeit ein ernsthaftes Problem.

Auch die digitale Arbeitsweise an sich behindert die Entwicklung völlig zuverlässiger Software. Viele technische Systeme sind ihrer Natur nach stetig in dem Sinne, daß sie durch „gutartige“ Funktionen beschreibbar sind – winzige Veränderungen der Eingangsgrößen bewirken auch nur sehr kleine Veränderungen in der Reaktion des Systems. Demgegenüber kann die kleinstmögliche Störung im Zustand eines digital arbeitenden Computers (das Umsetzen eines Bits von 0 auf 1 oder umgekehrt) eine radikal andere Antwort erzeugen. So war zum Beispiel ein einziges falsches Zeichen in der Spezifikation eines Steuerprogramms schuld daran, daß die Atlas-Rakete, welche die erste NASA-Planetensonde Mariner 1 trug, vom Kurs abwich und samt Raumsonde kurz nach dem Start zerstört werden mußte.

In allen anderen Bereichen des Ingenieurwesens bilden Einfachheit und schrittweises Verändern die Voraussetzung für vertrauenswürdiges Design. Anders bei der Programmentwicklung: Die völlig neuartigen und schier unbegrenzten Möglichkeiten der Software-Anwendungen verleiten die Entwickler dazu, diese Prinzipien zu vernachlässigen. Bei Programmierern wie Anwendern, die mit software-spezifischen Problemen nicht vertraut sind, erweckt dies einen falschen Eindruck von Sicherheit. Allein schon das Einfügen einer neuen Funktion in ein Programm jedoch kann unvorhergesehene Auswirkungen auf bestehende Programmteile haben.

Das Problem, in ein Design komplexe Entscheidungsregeln einzubauen und das Verhalten eines nicht-kontinuierlichen Systems vorherzusagen, ist nicht auf Software beschränkt. Bei der Entwicklung hochintegrierter digitaler Schaltkreise treten ähnliche Schwierigkeiten auf. Aber Software ist nach wie vor das bevorzugte Medium, um extrem komplexe, spezialisierte Entscheidungsregeln zu implementieren.

Ein unerwünschtes Systemverhalten kann nicht zuletzt auch durch Sabotage verursacht sein. Die Probleme mit Computersicherheit, Vertraulichkeit und Verschlüsselung verlangen indes spezielle Überlegungen, die über den Rahmen dieses Artikels hinausgehen.

Kriterien für Sicherheit und Zuverlässigkeit

Wenn nun perfekte Software in der Praxis unmöglich ist, wie können wir dann entscheiden, ob ein Programm die geforderte Zuverlässigkeit hat? Zunächst müssen die Sicherheitsanforderungen sorgfältig definiert werden, und zwar individuell für jeden Anwendungszweck. Beispielsweise verlangen amerikanische Behörden, daß das neue Luftverkehrsleitsystem der USA nicht länger als drei Sekunden pro Jahr ausfallen darf. Bei Zivilflugzeugen muß die Wahrscheinlichkeit für das Auftreten bestimmter katastrophaler Fehler kleiner als 10–9 pro Stunde sein.

Beim Festlegen solcher Kriterien muß man auch berücksichtigen, daß der Einsatz computerisierter Systeme möglicherweise einen Sicherheitsgewinn mit sich bringt, der auf andere Weise nicht zu erzielen wäre. Der Pilot einer Militärmaschine etwa ist zwangsläufig sehr viel gefährdeter als die Insassen eines Zivilflugzeugs. Die geforderte hohe Reaktionsfähigkeit der Maschine verbietet an sich schon ein konservatives Design, und ein neues Computersystem kann die Chancen für das Überleben im Kampfeinsatz selbst dann erhöhen, wenn es weniger sicher ist als die in der Zivilluftfahrt eingesetzten Systeme. Ganz ähnlich muß man beim Entwurf eines Fly-by-Wire-Systems für Passagierflugzeuge – etwa für den Airbus A320 oder die Boeing 777 – das Risiko eines durch die Software verursachten Unfalls gegen die Wahrscheinlichkeit abwägen, daß gerade die Software manche Katastrophen verhindern kann, die sonst durch Fehler der Piloten oder durch Materialversagen verursacht werden könnten (siehe „Computer-Piloten“ von Gary Stix, Spektrum der Wissenschaft, September 1991, Seite 68).

Nach unserer Meinung wäre blindes Vertrauen auf die unbedingte Zuverlässigkeit von Software ein großer Fehler. Um dies zu erläutern, müssen wir die verschiedenen Kriterien betrachten, auf denen das Vertrauen in ein gegebenes Programm beruht. Da ist zunächst einmal das Testen: Man läßt das Programm laufen, beobachtet direkt sein Verhalten und eliminiert Fehler, sobald sie auftreten. Diese Prozedur steigert die Zuverlässigkeit der Software, und aus dem gesammelten Datenmaterial läßt sich anschließend mittels ausgeklügelter statistischer Extrapolationsverfahren ein guter Schätzwert für die Zuverlässigkeit des Programms ermitteln.

Leider funktioniert dieser Ansatz nur dann, wenn die Anforderungen an die Zuverlässigkeit weit bescheidener sind als die, die man häufig für sicherheitsrelevante Anwendungen verlangt – etwa wenn man einen Fehler pro Jahr oder wenige Jahre toleriert. Verlangt man hingegen einen Wert von nicht mehr als 10–9 pro Stunde für das Auftreten eines Fehlers, müßte man das Programm ein Vielfaches von 109 Stunden (rund 100000 Jahre) laufen lassen. Bei den für Tests vertretbaren Zeitrahmen ist die ge-forderte Sicherheit nicht zu garantieren.

Das Problem ist ein typisches Beispiel für ein abnehmendes Nutzen-Kosten-Verhältnis: Je länger man ein Programm testet, desto unbedeutender sind die Fehler, die man dann noch findet; deren Beseitigung würde dann die Gesamtzuverlässigkeit oder -sicherheit praktisch nicht verbessern.

Edward N. Adams vom Thomas-J.-Watson-Forschungszentrum der Firma IBM in Yorktown Heights (US-Bundesstaat New York) analysierte anhand weltweit gesammelter Daten, die der Betriebszeit eines bestimmten Programms von vielen tausend Jahren entsprachen, die „Größe“ von Softwarefehlern. Die bemerkenswerteste Erkenntnis dabei war, daß ein Drittel aller entdeckten Fehler statistisch gesehen nur etwa alle 5000 Jahre auftrat (die Häufigkeiten anderer Programmfehler variierten um mehrere Größenordnungen; Bild 2). Der Anteil dieser seltenen Fehler war deshalb so hoch, weil häufiger auftretende schneller entdeckt und behoben werden konnten. Nach einer gewissen Zeit wurde die Zuverlässigkeit des Systems schließlich nur noch von den „5000-Jahr-Fehlern“ beeinträchtigt, wobei die Beseitigung eines einzelnen Fehlers dieser Art nur eine unerhebliche Verbesserung bewirkte.

Auch wenn man aus der Test- und Überarbeitungsphase extrapoliert, macht man implizit eine ungerechtfertigte Annahme – nämlich, daß ein einmal entdeckter Fehler auch tatsächlich eliminiert wird. In der Realität mißlingt jedoch manchmal die Korrektur; unter Umständen baut man dabei sogar einen neuen Fehler in das Programm ein. Da man über ihn nichts weiß, ist offen, wie er die Zuverlässigkeit beeinflußt – das System könnte nach der Korrektur sogar unzuverlässiger sein als zuvor.

Es wäre daher am besten, die Vorgeschichte des letzten Versagens völlig außer acht zu lassen. Diese Vorsichtsmaßnahme, die für sicherheitsrelevante Anwendungen eigentlich unabdingbar ist, verlangt von einem Bewerter, daß er ein korrigiertes Programm wie ein völlig neues behandelt. So würde nur die letzte Phase eines fehlerfreien Programmablaufs in die Sicherheitsbewertung einfließen. Aber selbst dieses konservative Vorgehen ist unzuverlässig. Unsere Untersuchungen haben nämlich ergeben, daß – unter durchaus plausiblen mathematischen Annahmen – nur eine Chance von 50 Prozent besteht, daß das Programm nach einer Korrektur ebenso lange fehlerfrei arbeitet wie zuvor.

Doch damit noch nicht genug. Um den aus den Tests abgeleiteten Fehlerwahrscheinlichkeiten überhaupt trauen zu können, muß man das Programm in realistischen Situationen erproben, damit fehlerauslösende Eingaben mit der gleichen Häufigkeit auftreten wie bei der späteren Anwendung. Zusätzlich sollte der Prüfer immer entscheiden können, ob die Programmausgabe tatsächlich korrekt ist. Die damit verbundenen Probleme ähneln denen bei Entwurf und Implementierung der Software selbst. Ein angemessenes Testumfeld muß alle Eventualitäten, denen die Software später begegnen kann, berücksichtigen. Aber so, wie einem bei der Systementwicklung das Unerwartete einen Streich spielen kann, ist es auch beim Entwurf von Testverfahren. Man tut daher gut daran, auch bei der Aussagefähigkeit von Tests und damit der Genauigkeit von Fehlerwahrscheinlichkeiten ein gewisses Maß an Skepsis zu bewahren.

Die Schwierigkeit, für irgendeinen speziellen Programmteil hohe Zuverlässigkeit oder Sicherheit nachzuweisen, liegt schlicht darin, daß uns das erforderliche Wissen fehlt. Das Vertrauen in ein komplexes Programm – so scheint die unangenehme Wahrheit zu lauten – kann nicht grenzenlos sein, sondern ist wesentlichen Schranken unterworfen. Allein aus der Beobachtung des Programmverhaltens kann man nicht erschließen, ob es 100000 Jahre lang zuverlässig funktionieren wird. Aber wie sonst könnten wir ein solches Vertrauen gewinnen?

Praktische Kriterien

Eine offensichtliche Voraussetzung für hohe Zuverlässigkeit ist, dieses Ziel schon bei der Software-Entwicklung selbst anzupeilen. Eine Methode beruht auf formalen Verfahren, die anhand einer mathematischen Beweisführung zeigen, daß ein Programm sich den Spezifikationen gemäß verhält. Tatsächlich haben solche Verfahren großes Interesse geweckt. Wenn auch derzeit praktische Probleme ihre Anwendbarkeit beschränken, können sie wirksam Programmierfehler verhindern, die bei der Umsetzung der Spezifikationen in das konkrete Programm auftreten.

Bedauerlicherweise müssen die Spezifikationen ebenfalls formale Aussagen sein – das heißt, die Anforderungen der Nutzer sind in einer mathematischen Sprache zu formulieren. Dies ist alles andere als einfach: Man muß dazu jene Aspekte der realen Welt, die formal beschrieben werden sollen, sorgfältig auswählen und überdies sowohl mit den einzelnen praktischen Problemen der Anwendung als auch mit der formalen Sprache selbst gut vertraut sein. Bei diesem Prozeß schleichen sich Fehler recht wahrscheinlich ein, so daß man nicht guten Gewissens behaupten kann, das Programm werde nie versagen.

Eine andere Methode, die heute häufig verwendet wird (zum Beispiel in der Luft- und Bahnverkehrstechnik), ist Fehlertoleranz durch redundante Programmierung. Typischerweise läßt man dazu unterschiedliche Teams mehrere Versionen des Programms erstellen. Jede Programmversion liefert quasi nur deren Meinung über die richtige Ausgabegröße. Die Ausgaben werden dann in einer Art Schiedsgerichtsentscheidung zu einer einzigen zusammengefaßt; sie gilt als richtig, wenn die Mehrzahl der Versionen die korrekte Antwort gegeben hat (Bild 3).

Mit einer solchen mehrfachen Programmauslegung läßt sich offenbar kostengünstig hohe Zuverlässigkeit erreichen. Freilich können auch verschiedene Entwicklerteams dieselben Fehler machen (etwa aufgrund von Gemeinsamkeiten in ihrer Ausbildung) oder unterschiedliche, die aber das gleiche Systemversagen zur Folge haben. In beiden Fällen würde der „Schiedsrichter“ eine falsche Ausgabe erzeugen.

Um die fehlertolerante Software zu bewerten, muß man die statistische Korrelation zwischen den Fehlern der verschiedenen Versionen abschätzen. Leider erweist sich diese Aufgabe als ebenso schwierig wie beim Versuch, das Gesamtsystem als eine Einheit zu behandeln – und wir haben die damit verbundenen Probleme schon kennengelernt.

Es scheint demnach keinen anderen Weg zu geben, als die Zuverlässigkeit direkt zu bewerten – mit Hilfe von Methoden, deren Genauigkeit freilich begrenzt ist. Wie gehen Aufsichtsbehörden und Software-Nutzer mit dieser Unsicherheit um?

Es gibt drei Ansätze. Einer besteht darin, konstruktionsbedingte Fehler als „nicht-quantifizierbar“ zu definieren und keine speziellen Anforderungen an die Software zu stellen. Diese Methode wendet man heute recht häufig an. Die Luftaufsichtsbehörde der Vereinigten Staaten (Federal Aviation Administration) zum Beispiel beschreibt in ihrem Schriftstück 25.1309-1A „akzeptable“ Mittel, mit denen die Einhaltung einiger nationaler Bestimmungen für die Zivilluftfahrt belegt werden kann: Katastrophale Fehlerbedingungen (die schlimmste Kategorie) müssen „so unwahrscheinlich sein, daß ihr Auftreten während der gesamten Operationsdauer aller Flugzeuge eines gegebenen Typs nicht zu erwarten ist“. Die vorgeschlagene quantitative Größe entspricht einer Fehlerwahrscheinlichkeit von nicht mehr als 10–9 pro Flugstunde. Software ist jedoch explizit von dieser Richtlinie ausgenommen, „da es nicht möglich ist, Anzahl oder Art der nach Abschluß von System-Entwurf, Entwicklung und Erprobung möglicherweise noch verbliebenen Softwarefehler abzuschätzen“.

In ähnlicher Weise vermeidet das häufig verwendete Dokument der Funktechnischen Kommission für Luftfahrt (Radio Technical Commission for Aeronautics), RTCA/DO-178A, die Definition von numerischen Gütekriterien für Software. Das Dokument, das Richtlinien für Hersteller angibt, die für ihre Produkte eine Zulassung der Luftfahrtbehörden benötigen, lehnt es explizit ab, quantitative Größen oder Methoden für die Bewertung von Zuverlässigkeit oder Sicherheit von Software vorzuschreiben. Statt dessen erachtet die Kommission eine korrekte ingenieursmäßige Arbeitsweise – straffes Management, gründliche Begutachtungen und Tests sowie die Analyse früherer Fehler – für wichtiger als quantitative Verfahren. Die grundlegende Aussage des Dokuments lautet, daß „die Entwickler einen disziplinierten Zugang zur Software einschlagen müssen: Anforderungsbeschreibung, Entwurf, Entwicklung, Tests, Konfigurations-Management und Dokumentation“. Das heißt, die beste Garantie für Zuverlässigkeit ist nachzuweisen, daß größtmögliche Sorgfalt für den Entwurf aufgewendet worden ist.

Welchen Wert hat eine solche Aussage? Unseres Erachtens keinen großen: Es gibt keinen Beweis dafür, daß überlegene Entwurfs- und Produktionsverfahren eine Garantie für bessere Produkte bieten. Wir können nicht einmal sicher sein, ob die gegenwärtig besten Methoden jemals ausreichende Zuverlässigkeit für anspruchsvollere Anwendungen erreichen können.

Vermeidet man aber eine Quantifizierung der Softwaresicherheit, ist eine Bewertung des Gefahrenpotentials vieler Systeme kaum möglich – insbesondere solcher, bei denen vor ihrer Inbetriebnahme eine umfassende probabilistische Risikoabschätzung erforderlich ist. Für ein durch Spannungen oder Verschleißprozesse verursachtes Materialversagen lassen sich zwar mit hinreichender Genauigkeit Wahrscheinlichkeiten angeben. Aber dies nützt für die Bewertung des Gesamtsystems (bestehend aus Hard- und Software) gar nichts, wenn die einzige Aussage zur Softwaresicherheit lautet, es seien die größten Anstrengungen unternommen worden, Fehler zu vermeiden. Einfach bestmögliche Sorgfalt zu verlangen, löst daher das Problem nicht. Selbstverständlich wäre es unsinnig, Verfahren, die bekanntermaßen Zuverlässigkeit und Sicherheit erhöhen, nicht anzuwenden, nur weil wir ihren Nutzen nicht quantifizieren können. Standards, die den Einsatz solcher Methoden verlangen, sind gewiß hilfreich; sie helfen uns aber nicht zu erfahren, ob die Software den erforderlichen Sicherheitsansprüchen genügt.

Der zweite – unseres Erachtens bessere – Ansatz verlangt, das System so zu konstruieren, daß die Rolle der Software darin nicht zu kritisch ist. „Nicht zu kritisch“ bedeutet hier, daß man die Anforderungen an die Zuverlässigkeit so moderat hält, daß man ihre Erfüllung vor Inbetriebnahme des Systems nachweisen kann. Dieser Ansatz wurde in Großbritannien für den neuen Sizewell-B-Kernreaktor gewählt; dort muß die noch tolerierbare Wahrscheinlichkeit für das Auftreten eines Softwarefehlers lediglich kleiner als 10–4 sein (Bild 4).

Es gibt bewährte Methoden, die Kritizität einer einzelnen Komponente für die Gesamtsicherheit zu beschränken. Zum Beispiel kann man eine überwiegend computergesteuerte Industrieanlage mit Sicherheitssystemen ausstatten, die nicht von einer Software oder irgendeinem anderen komplexen Design abhängig sind. Ein Sicherheits- oder Notsystem führt üblicherweise einfachere Funktionen aus als die Hauptsteuerung, so daß es auch zuverlässiger ist. Sicherheit kann erzielt werden, wenn die Notsysteme völlig vom Hauptsystem getrennt sind. Sie könnten technisch anders konstruiert sein oder andere Sensoren, Bedienungselemente und Energieversorgungen verwenden. In diesem Fall kann man die Wahrscheinlichkeit, daß Haupt- und Notsystem gleichzeitig versagen, wohl mit gutem Recht als gering erachten.

Der dritte Ansatz besteht darin, die heutigen Unzulänglichkeiten der Software zu akzeptieren und sich mit einer geringeren Sicherheit des Gesamtsystems zufriedenzugeben. Schließlich mag es sein, daß die Gesellschaft manchmal aus vielleicht irrationalen Gründen ein extrem hohes Maß an Sicherheit verlangt. Medizinische Geräte etwa sind gute Beispiele. Bei chirurgischen Eingriffen unterlaufen nicht gerade selten Fehler, und es müßte daher doch eigentlich folgerichtig sein, eine computergesteuerte Operationsmaschine zu akzeptieren, wenn sie mindestens so zuverlässig wie der menschliche Arzt arbeiten würde. In der nahen Zukunft werden solche Roboter vermutlich sogar Operationen durchführen können, die die Kunstfertigkeit von Chirurgen weit übertreffen.

Alle drei Ansätze, mit Softwaresicherheit umzugehen, mögen recht unbefriedigend erscheinen. Jeder begrenzt entweder den Grad der Systemsicherheit oder die Komplexität des Programms. Vielleicht besteht der einzige Weg, mehr über die notwendigen Kompromisse zwischen Sicherheit und Komplexität zu lernen, darin, das Versagen (oder das klaglose Funktionieren) von Software im direkten Betrieb zu untersuchen.

Leider gibt es zu wenig Datenmaterial, um diesbezüglich statistische Aussagen treffen zu können. Informationen über Softwareversagen werden selten publik gemacht, da die Firmen um ihre Konkurrenzfähigkeit fürchten. Noch größere Angst dürften sie vor zunehmenden Vorbehalten der Öffentlichkeit gegen Softwareprodukte haben. Viele könnten die Entdeckung eines Programmfehlers als Zeichen niedriger Produktionsstandards ansehen, obwohl gerade dies ein Beleg für eine sehr gründliche Überprüfung einer qualitativ hochwertigen Software sein mag. Geheimniskrämerei kann aber letztlich nur bewirken, daß die Erwartungen an die Sicherheit unrealistisch hoch werden. Einige Fachleute haben vorgeschlagen, das Aufzeichnen und Bekanntmachen von Fehlerdaten bei sicherheitsrelevanten Systemen gesetzlich vorzuschreiben. Solche Bestimmungen würden die Befürchtungen gegenstandslos machen, daß Firmen, die solche Daten freiwillig publizieren, dadurch Nachteile erleiden könnten.

Doch wie auch immer eine solche umfangreiche Datensammlung erstellt würde – sie könnte mit der Zeit dazu beitragen, die Wirksamkeit unterschiedlicher Produktions- und Validierungsverfahren zu messen. Anhand dieser Informationen könnte man realistischere Regeln für die Beurteilung der Vertrauenswürdigkeit von Softwaresystemen aufstellen. So könnten etwa für Software, die nicht vollständig statistisch überprüft wurde, die noch vertretbaren Aussagen über ihre Sicherheit an explizite, von ihrer Komplexität abhängige Obergrenzen gebunden werden. Dadurch würden sich Aussagen über Zuverlässigkeit und Sicherheit von Software mit heute noch unvorstellbarer Exaktheit treffen lassen.

Bis es soweit ist, sollten wir jeglicher abenteuerlich hoch erscheinenden Zuverlässigkeitsangabe mit Mißtrauen begegnen. Angesichts der erreichten Komplexität von Software erscheint uns Skepsis als die sicherste Vorgehensweise.


Aus: Spektrum der Wissenschaft 1 / 1993, Seite 64
© Spektrum der Wissenschaft Verlagsgesellschaft mbH