Bundesamt für Sicherheit in der Informationstechnik

G 2.213 Fehlende oder unzureichende Qualitätssicherung des Softwareentwicklungsprozesses

Eine fehlende oder unzureichende Qualitätssicherung während der Software-Entwicklung kann dazu führen, dass das Projekt verzögert wird oder scheitert. Insbesondere wenn die sichere Implementierung nicht ausreichend geprüft wird, drohen Sicherheitslücken durch Schwachstellen in der ausgelieferten Software.

Ist die Qualitätssicherung nicht fest im Entwicklungsprozess verankert, kann dem Risiko, welches von Implementierungsfehlern, Konzeptionsfehlern oder gar bewusster Manipulation ausgeht, nicht angemessen begegnet werden. Dabei sollte die Aufmerksamkeit nicht nur selbst entwickelten Bestandteilen, sondern gerade auch externen Beiträgen Dritter oder übernommener Bestandteile z.B. aus externen Bibliotheken gelten. Die Offenlegung des Quellcodes, nach dem Open Source-Prinzip, und die damit prinzipiell verbundene, oft aber nicht genutzte, Möglichkeit zur Untersuchung durch externe Experten kann eine eigene systematische Qualitätssicherung nicht ersetzen.

Beispiele:

  • Ein Praktikant erhält in einem Software-Unternehmen Vollzugriff auf alle Quellcode-Ressourcen. Er lässt sich von einem Konkurrenten des Unternehmens für das Einschleusen von Schadcode in zentrale Software-Komponenten engagieren. Diese Manipulation wird wegen fehlender Qualitätssicherung erst Monate später entdeckt und zu diesem Zeitpunkt bereits in Produktivsystemen eingesetzt.
  • Es ist durchaus nicht ungewöhnlich, dass dieselben über Bibliotheken eingebundenen, in OEM-Firmware enthaltenen oder einfach nur kopierten Standard-Codebausteine in den Produkten verschiedener Hersteller Anwendung finden. Häufig werden innerhalb der Entwicklungsumgebung aus praktischen Gründen auch Daten verwendet, die nicht zur Veröffentlichung bestimmt sind. Was passieren kann, wenn dabei notwendige Anpassungen bzw. Bereinigungsschritte unterbleiben, zeigt das Ergebnis einer 2015 veröffentlichten Sicherheitsstudie. Die Forscher fanden zahlreiche private Schlüssel für SSL -Zertifikate und SSH -Zugänge in der veröffentlichten Firmware verschiedenster Produkte. Unter anderem fanden sich Zertifikate aus den SDK s von OEM-Lieferanten in den eigens erstellten Firmware-Versionen zahlreicher Kunden wieder. Da deren veröffentlichte Firmware auch jederzeit von Angreifern analysiert werden konnte wurde so eine enorm große Anzahl von Anwendern dieser Produkte der potentiellen Gefahr unberechtigter Zugriffe ausgesetzt.
  • 2014 ging ein simpler Programmierfehler in einem Zusatzmodul der Open-Source-Bibliothek OpenSSL als Heartbleed-Bug in die Geschichte ein. Durch eine fehlende Längenprüfung war es Angreifern möglich, zufällige Speicherinhalte, welche auch geheime kryptographische Schlüssel oder Kennwörter enthalten konnten, von Gegenstellen abzurufen, welche die Bibliothek zur Implementierung von TLS nutzen. Der unbeabsichtigt fehlerhafte Programmcode war drei Jahre zuvor durch einen externen Entwickler eingereicht worden und wurde im Jahr darauf durch das interne Entwicklerteam in den produktiven Sourcecode übernommen. Die enorme Popularität der OpenSSL-Bibliothek führte schließlich dazu, dass der fehlerhafte Code weltweit in einer Vielzahl von Produkten und Systemen Verbreitung fand.
  • Vermutlich seit der ersten Version aus dem Jahre 1989 enthielt der Sourcecode des Kommandozeileninterpreters Bash eine schwerwiegende Schwachstelle, die 2014 als Shellshock bekannt wurde. Sie ermöglichte es entfernten Angreifern unter bestimmten Umständen Code zur Ausführung auf betroffene Systeme wie z.B. Webserver, DHCP -Clients etc. einzuschleusen. Zwar wurde dank der umsichtigen Vorgehensweise des Entdeckers bereits bei Bekanntwerden ein erster Patch veröffentlicht, dieser behob das Problem selbst aber auch nicht vollständig. Folgende Analysen durch Sicherheitsforscher förderten schnell weitere Lücken zu Tage, die durch weitere Patches geschlossen werden mussten. Damit zeigt sich zwar, dass die öffentliche Verfügbarkeit des Quellcodes bei Eintreten des schlimmsten Falles die Analyse des Quellcodes durch interessierte Experten erleichtert und zur raschen Behebung von Schwachstellen beitragen kann. Der Umstand eines seit 25 Jahren unentdeckt bestehenden Fehlers zeigt aber deutlich, dass diese Form der fallweisen externen Qualitätssicherung eigene Prozesse keinesfalls ersetzen kann.

Stand: 15. EL Stand 2016

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK