Softwarequalität als Fundament der sicheren Softwareentwicklung

Viele Websites und Onlinedienste sind für Angriffe nicht gewappnet. Moderne Software ist heutzutage so komplex, dass Fehler nicht oder nur schwer erkennbar sind.

Das sind keine Neuigkeiten - man liest diese oder ähnliche Feststellungen und Schreckensmeldungen über Kundendatenverluste oder andere Sicherheitsprobleme (siehe Heartbleed, Shellshock, Spectre & Meltdown) fast wöchentlich, nicht nur in einschlägigen Blogs, Artikeln, Foren zur Informationstechnologie oder Softwareentwicklung, sondern generell in den Medien.

Die steigende Komplexität von Software stellt gleichzeitig die Software-Entwicklung vor große Herausforderungen. Die gestiegene Komplexität ergibt sich durch die Durchdringung mit Software von immer mehr Lebensbereichen, unter anderem durch das Internet of Things, die zunehmende Vernetzung, und die zunehmende Anzahl von Plugins, die aus Sicht der Host Plattformen unvorhersehbare Funktionalitäten mit sich bringen. Diese große Komplexität ist ein Einfallstor für Sicherheitslücken. Zwei typische Beispiele sind SQL Injections und falsche programmatische Behandlung von Buffer Overflows. Gegen derartige grundlegende Mängel in der Softwarequalität helfen auch die besten kryptographischen Methoden nicht.

Derartige Sicherheitslücken sind aber nicht absichtlich in die Software eingebaut worden. Sie basieren entweder auf Programmier- oder Designfehlern, d.h. sie stellen Mängel in der Softwarequalität dar. Beispielsweise passiert es häufig, dass unter Termindruck Tests nicht in vollem Umfang implementiert und durchgeführt oder überhaupt unterlassen und "auf später" verschoben werden um den geplanten bzw. zugesagten Funktionsumfang für den fixierten Termin halten zu können.

Selten, dass jemand aus der IT-Branche nicht schon erlebt hätte, dass ein Projekt auf Grund von schlechter Softwarequalität verzögert, verteuert oder überhaupt abgebrochen werden musste. Im "Chaos-Report" der Standish Group werden alle zwei Jahre Zahlen publiziert, die sich aus der Analyse von über 50.000 Projekten der zurückliegenden 5 Jahre ergeben. 2020 waren zum Beispiel 19% aller Projekte fehlgeschlagen, 50% gefährdet und nur 31% erfolgreich. Immerhin gibt es eine positive Langzeitentwicklung (zum Vergleich 1994: 31% fehlgeschlagen, 53% gefährdet und nur 16% erfolgreich).

Was ist Qualität überhaupt? Das liegt zu einem Teil im Auge des Betrachters, wird aber auch von externen Faktoren (Anforderungen) bestimmt - daher lässt sich auch keine allgemeingültige Definition finden. Es lässt sich aber treffend darüber definieren was es nicht ist:

"Qualität ist kein Zufall, sie ist immer das Ergebnis intelligenten Bestrebens."
- John Ruskin (1819-1900)

Das heißt, dass Qualität Aufwand bedeutet. Es muss Arbeit - intelligente Arbeit - investiert werden, um Qualität zu erreichen. Softwarequalität ist hier keine Ausnahme. Oftmals sind Softwareprojekte aber unter-budgetiert, und Aufwandsabschätzungen sind am Minimum; Tests und Prüfungen werden nicht rigoros verlangt bzw. umgesetzt.

Treten wir einen Schritt zurück, und fragen wir: Was ist überhaupt nötig um Software sinnvoll erstellen zu können? Dabei sind die folgenden wichtigsten Phasen zu durchlaufen:

  • Anforderungsanalyse
  • Design & Architektur
  • Umsetzung & Tests
  • Betrieb (Wartung)

In diesen Phasen gibt es Maßnahmen, die die Qualität der in jeder Phase entstehenden Artefakte sicherstellen sollen. Wie diese Phasen durchlaufen werden, und welche Feedback-Schleifen dabei sinnvollerweise entstehen, ist Thema von Prozessmodellen. In agilen Modellen, die seit den 2000er-Jahren an Popularität gewonnen haben, wird Software inkrementell und iterativ entwickelt. Das bedeutet, dass in mehreren zeitlich begrenzten Zyklen (Iterationen) funktionale Teile (Inkremente) des Gesamtsystems erstellt und dabei die ersten drei der oben genannten Phasen durchlaufen werden. Dabei wird die vorhandene Funktionalität evaluiert, und es werden notwendige Anpassungen an Anforderungen, Design und Architektur für die nächste Iteration der Umsetzung eingeplant. Hier kann an der Qualitätsschraube gedreht werden. Dass das natürlich Kosten verursachen kann ist offensichtlich, aber je früher Fehler in Design und Architektur des zu erstellenden Systems gefunden werden, desto "billiger" können diese Fehler bereinigt werden. Die Metrik von Barry Boehm besagt, dass die Kosten exponentiell steigen wenn sie in späteren Phasen der Software-Entwicklung gefunden werden. Im Detail ist diese nicht mehr zur Gänze nachzuvollziehen [1], aber die grundsätzliche Aussage ist nach wie vor sinnvoll.

Ein Kritikpunkt ist, dass diese Metrik aus den 1970er-Jahren stammt, wo noch anders, nämlich wasserfallartig, entwickelt wurde. Mittlerweile wurden die damals gängigen Entwicklungsprozesse durch agile Prozesse ersetzt, in denen fast alle Phasen in jeder Iteration durchlaufen werden und Feedbackschleifen für Korrekturen sorgen. Dennoch leuchtet es ein, dass ein Fehler der in einer früheren Phase gefunden wird, weniger Schaden anrichten kann, als derselbe Fehler, der in der Betriebsphase der Software entdeckt und behoben werden muss.

Insgesamt sind die Kosten für Softwarefehler enorm hoch, vor allem weil es sich in den meisten Fällen um vorhersehbare und damit vermeidbare Fehler handelt. Nur als Beispiel, der 5. "Software Failwatch"-Bericht [2] von Tricentis [3] beziffert den monetären Verlust durch Softwarefehler für das Jahr 2017 auf 1,7 Billionen (10¹²) US$. Von diesen Softwarefehlern waren dem Bericht zufolge 3,7 Milliarden Menschen - also die halbe Weltbevölkerung - betroffen.

Softwarequalität durch Agilität in Kombination mit bewährten Entwicklungspraktiken

Tatsächlich sind aber in den notwendigen Phasen der Softwareentwicklung in der Theorie bereits qualitätssichernde Maßnahmen enthalten. Das geht von Review-Zyklen in der Anforderungsanalyse, der Verwendung von Design-Patterns in Analyse und Design, über Codereviews (automatisierte statische Analysen oder direkt beim Programmieren mittels Pair-Programming, oder in eigenen Review-Sessions), bis zu ausgefeilten Teststrategien (Test-First, TDD) in Implementierungs- und Integrationsphase sowie vor der Inbetriebnahme. Des weiteren haben sich in der agilen Entwicklung kurze Release-Zyklen etabliert. Dadurch wurde die Tätigkeit der Integration, die zu Anfangszeiten der (agilen) Entwicklung noch manuell durchgeführt wurde, immer wichtiger. Mittlerweile kann auch diese Tätigkeit mit Hilfe von speziellen Entwickler-Werkzeugen wie Quellcodeverwaltung und Continuous Integrations-Frameworks automatisiert werden. Das bedeutet, dass sobald Code im Repository geändert wird, automatisch die gesamte Software kompiliert wird, Tests durchlaufen werden, und Berichte über den Erfolg des Baus oder Fehler der Tests erstellt werden. Dieser Bericht ist für alle Entwickler über das Continuous Integration Werkzeug einsehbar. Dadurch ist schnelles Feedback zur Gesamtfunktionalität und auch der Codequalität möglich, die lange Wartezeiten vermeidet. Das hilft die Entwicklung auf Clean-Code-Prinzipien und handwerklicher Exzellenz zu fokussieren, die wiederum hohe Softwarequalität ermöglicht.

Sichere Software durch Softwarequalität

Die neuen Anforderungen an die Sicherheit der Software (Daten-, Computer- und Netzwerksicherheit) entstehen, wie oben beschrieben, durch die steigende Software-Komplexität, sowie die stark angestiegene Zahlen von Nutzer/innen. Diese müssen nun durch weitere Maßnahmen in allen Entwicklungsphasen berücksichtigt werden. Das wird in Prozessmodellen wie den "Seven Touchpoints for Software Security" von McGraw oder dem "Security Development Lifecycle" (SDL) von Microsoft umgesetzt - beide seit ca. 2004 in Anwendung. Diese Touchpoints bringen den Fokus auf die Sicherheit in die verschiedenen Phasen der Entwicklung:

  • Anforderungsanalyse
    • 1 - Sicherheitsanforderungen
    • 2 - Abuse-cases: Wie könnte die Software und ihre Features missbraucht werden?
    • 3 - Risiko Analyse: Was sind realistische, was sind besonders gefährliche Risken?
  • Design & Architektur
    • 3 - Risiko Analyse: Welche Angriffspunkte sind realistisch und besonders gefährlich aufgrund der Architektur?
    • 4 - Sicherheitstests (Planung): Welche Tests müssen implementiert werden um die Abuse Cases und die gefundenen Risiken automatisiert testen zu können?
  • Umsetzung & Testen
    • 4 - Sicherheitstests: Die obigen Tests müssen implementiert werden.
    • 5 - Code Reviews: Statische Analysen (Metriken) sowie laufendes Code-Review z.B. durch Pair Programming oder Expert/innen fördern die allgemeine Softwarequalität.
    • 6 - Penetration testing (Planung): Systematisches Testen gegenüber bekannten Angriffsvektoren.
  • Betrieb (Wartung)
    • 6 - Penetration testing: Laufendes systematisches Testen gegenüber sich ändernden und neu hinzukommenden Angriffsvektoren.
    • 7 - Security operations: Laufendes Monitoring und Logging der Software im Betrieb, und Erkennen von tatsächlichen Angriffsmustern zur Entwicklung von Gegenmaßnahmen.

Durch diese Maßnahmen wird erreicht, dass Softwaresicherheit durch den gesamten Softwareentwicklungszyklus mitgedacht und umgesetzt wird. Wichtig ist: Diese Maßnahmen existieren nicht isoliert, und erfüllen nicht alleine die neuen Herausforderungen an die Sicherheit der Software. Vielmehr bauen sie auf funktionierenden Praktiken der modernen Softwareentwicklung auf. Das heißt erstens, sie verlangen notwendigerweise funktionierende Softwareentwicklung. Zweitens können sie perfekt in Softwareentwicklung integriert werden, besonders auch in agile da dort aufgrund der kurzen Iterationen rasch notwendige Anpassungen vorgenommen werden können. Wird das praktiziert, ist die Wahrscheinlichkeit hoch, dass die resultierende Software von guter Qualität ist, und damit nicht "aus Versehen" Sicherheitslücken beinhaltet.

Da die Durchdringung aller Lebensbereiche mit Software, die Nutzerzahlen, die Komplexität der Anwendungen und der Grad an Vernetzung eher weiter steigen als sinken werden, werden die Anforderungen an die Sicherheit zur normalen Anforderungen der Softwarequalität. Das heißt, in Zukunft wird man unter guter Software eine Software verstehen, die Sicherheits-Aspekte in allen Bereichen berücksichtigt. Dadurch müssen die oben beschriebenen Maßnahmen zur Steigerung der Softwaresicherheit in jeden Software-Entwicklungsprozess Einzug halten.

Referenzen:

Autor:

  • Christian Schindler, FH JOANNEUM
Letzte Aktualisierung: 12. Mai 2023

Für den Inhalt verantwortlich: FH JOANNEUM