Kontrolle statt Vertrauen
Qualitätssicherung von Fremdcodes

Kaum ein Entwicklerteam schreibt heute noch jede Codezeile selbst. Die industrielle Produktion hat auch in der Softwareentwicklung längst Einzug gehalten. Doch wäre es leichtfertig, sich auf die Qualität des Codes von Dritten blindlings zu verlassen. Im Rahmen einer Sourcing-Strategie bei der Entwicklung nimmt deswegen die Qualitätssicherung eine zentrale Rolle ein. Die große Hürde dabei ist allerdings, dass ein großer Teil des Fremdcodes binär vorliegt. Mit geeigneten Werkzeugen kann aber auch dieser einer strengen Analyse unterzogen werden.

(Bild: GrammaTech Inc.)

Das Internet of Things spielt eine zentrale Rolle bei der Digitalisierung: Die Grundlage vieler disruptiver Geschäftsmodelle bilden zahlreiche Sensoren und Aktoren, die über das Internet mit dem Rechenzentrum und auch untereinander verbunden sind. Für die Entwicklerteams im Embedded-Bereich bedeutet das zunächst, dass die Projekte durch neue, zusätzliche Anforderungen an die Software komplexer werden.. Die meisten Unternehmen reagieren darauf mit dem in der fertigenden Industrie etablierten und bewährten Muster, die Fertigungstiefe in der Softwareentwicklung zu reduzieren und Code-Bestandteile aus externen Quellen zu beschaffen. Das Marktforschungsunternehmen VDC Research ermittelte im Jahr 2016, dass bei Embedded-Applikationen fast 45 Prozent der Codebasis aktueller Projekte von Dritten stammt. Meist handelt es sich dabei um spezielle Komponenten wie Grafik- und Windowing-Toolkits, Kryptografie-Bibliotheken oder Datenbanken.

Risiken nicht unterschätzen

Mit dem Einsatz fremder Codebestandteile verringern Unternehmen zwar die Time to Market ihrer Anwendungen, handeln sich aber ein schwer einzuschätzendes Risiko ein: Ist der Code aus externen Quellen sicher und entspricht er den Standards der eigenen Entwicklungsabteilung?

Security und Zertifizierung betroffen

Unter anderem sind folgende Bereiche davon betroffen: Zum einen der Bereich Security. Dort werden mit dem Einsatz von Code aus externen Quellen möglicherweise vorhandene Sicherheitslücken in das eigene Projekt übernommen. Das stellt das eigene Unternehmen vor zwei Herausforderungen: Sicherheits-Updates des Codezulieferers müssen zeitnah in die eigene Anwendung übernommen und an die Kunden ausgerollt werden. Zudem kann der fremde Code versteckte und auch böswillige Schwachstellen aufweisen, für die das eigene Unternehmen geradestehen muss. Zum anderen ist der Bereich der Zertifizierung betroffen: Entwickler, die Anwendungen in kritischen Bereichen wie etwa Medizintechnik entwickeln, müssen sich beim Programmieren und beim Testing an klare Standards und Normen halten. Code Dritter muss nach denselben Standards zertifiziert sein. Die entsprechende vollständige Dokumentation seitens des Code-Zulieferers muss also vorliegen – oder der fragliche Code muss selbst zertifiziert werden. Bei Binärcode kann das ohne die richtigen Tools extrem schwierig werden.

Qualität: Fehler im externen Code müssen nicht gleich sicherheitsrelevant sein. Performance-Probleme oder Abstürze reichen aus, um den eigenen guten Ruf zu ruinieren. Zusätzliche Kosten für Updates oder sogar eine komplette Neuentwicklung sind da schon fast das kleinere Übel.
Es ist deswegen im Rahmen einer Sourcing-Initiative unverzichtbar, Schwachstellen im eigenen und in fremdem Code mit geeigneten Maßnahmen innerhalb des Software-Development-Lifecycles aufzuspüren und zu beseitigen.

Herausforderung Binärcode

Bei Open-Source-Komponenten ist das noch relativ einfach. Der Quellcode liegt vor, das Programm oder die Bibliothek kann mit den üblichen Test- und Analysemethoden geprüft werden. Fortschrittliche Tools sind dabei auch in der Lage, gut im Code versteckte Fehler oder Angriffe zu erkennen. Zudem liegt der Code in einer Form vor, die ein geübter Entwickler zumindest bis zu einer gewissen Komplexität nachvollziehen kann. Ganz anders sieht es jedoch aus, wenn die Komponenten nur binär ausgeliefert werden. Diese können mit den meisten Analyse-Tools nicht überprüft werden. Somit bleibt nur das aufwändige Testing mit definierten Testfällen. Oder der Code bleibt ungeprüft.

Ausgereift, jedoch mit Schwächen

Die dynamischen Testmethoden sind zwar sehr ausgereift, haben aber eine prinzipielle Schwäche: Beim Testing wird ein in der Entwicklung oder im Review befindliches Programm ausgeführt und in mehreren, unterschiedlichen Szenarien geprüft. Diese sind in der Regel praxisnah definiert. Code, der im Rahmen der Testfälle nicht zur Anwendung kommt, hinterlässt in diesem Verfahren auch keine Hinweise auf mögliche Fehler. Auch häufig genutzte Angriffsvektoren wie etwa Time Bombs, die erst mit Ablauf eines bestimmten Datums aktiv werden, sind durch das klassische Testing nicht zu finden. Anders ist das bei Tools zur statischen Codeanalyse: Diese erstellen – vereinfacht gesagt – ein Modell des Codes und betrachten alle möglichen Daten- und Steuerungsströme. Nur wenige Anbieter sind derzeit in der Lage, das Verfahren der statischen Analyse auf binären Code anzuwenden. Das liegt zum einen an der hohen Komplexität, da viele analyserelevanten Informationen nur im Quellcode zu finden sind, im binären Zustand jedoch nicht. Zum anderen muss das Analyse-Tool die Struktur des ursprünglichen Codes wiederherstellen – obwohl Binärcode kein Konzept einer Struktur kennt. Ein Analyse-Tool, das sowohl Binär- als auch Quellcode statisch analysieren kann, ist CodeSonar von GrammaTech. CodeSonar ist in der Lage, sowohl ausführbare Dateien als auch binäre Bibliotheken auf Fehler und Schwachstellen zu prüfen. Das Tool erzeugt dazu ein Modell des gesamten Programms mit allen Source- und Binary-Bestandteilen und erstellt daraus eine einheitliche Präsentation, die die Semantik beider Teile konsistent abbildet. Um mögliche Fehler zu erkennen, durchläuft das Werkzeug das Modell interprozedural und sucht nach Anomalien.

Statische Analyse als zentrale Instanz

Es ist also auf jeden Fall sinnvoll, Code aus externen Quellen ebenso zu überprüfen wie die eigene Entwicklungsarbeit. Dazu empfehlen fast alle Standards ab einer gewissen Kritikalität der Anwendung den Einsatz von statischer Analyse. Für den Erfolg bei der Qualitätssicherung ist ein orchestriertes Vorgehen entscheidend. Tests und statische Analysen sollten als integrale Bestandteile des Entwicklungsprozesses etabliert werden. Dazu gehört, ein Vorgehensmodell festzulegen und zu forcieren, das den Software Development Lifecycle in einzelne Phasen gliedert. Innerhalb dieser Phasen sollte auch das Testing und die Code-Analyse fest als fortlaufender Prozess zur Qualitätssicherung eingeplant werden. Vor allem in den frühen Phasen der Softwareentwicklung ist meist noch kein wirkliches Testing möglich, da noch kein lauffähiger Gesamtcode existiert. Dabei ist die statische Analyse unverzichtbar, denn es gilt die Regel: Je später ein Fehler gefunden wird, desto aufwändiger und kostspieliger ist seine Beseitigung. Zudem sollte ein Review-Prozess implementiert werden, den alle Veränderungen des Codes durchlaufen müssen. So lässt sich weitgehend sicherstellen, dass vorhandene Sicherheitslücken gefunden und beseitigt werden. Die Entwickler-Teams können dadurch ihre Anwendungen sicherer machen und gleichzeitig die Time to Market verringern. Doch bei aller organisatorischen und technologischen Unterstützung: Tools können dem Entwickler nur Hinweise liefern, wo mögliche Fehler liegen. Ohne manuelle Prüfung und Tests durch erfahrene Programmierer wird es keine sichere Software geben, die den Anforderungen eines IoT-basierenden Geschäftsmodells gerecht wird.

Datum:22. November 2017

Autoren:Mark Hermeling, Senior Director Product Marketing, GrammaTech, Inc.

Themen: Fachartikel, Security, Technik

Webseite: www.grammatech.com

Downloads: