Wieso die Inventarisierung von Softwarekomponenten so wichtig ist

In nahezu jeder proprietären Software stecken verschiedene Open-Source-Komponenten. Das hat Vorteile, birgt aber auch Risiken, wie nicht zuletzt die Sicherheitslücke in log4j gezeigt hat. Unternehmen sollten reagieren und unbedingt eine vollständige Liste der Softwarekomponenten pflegen, die in den eingesetzten Anwendungen zum Einsatz kommen.

 

Wenn Unternehmen und Organisationen proprietäre Anwendungen nutzen, kommen in den weitaus meisten Fällen Open-Source-Komponenten zum Einsatz. Moderne Softwareanwendungen sind eine komplexe Mischung aus proprietären, Open-Source- und Drittanbieterkomponenten, Kommunikations-APIs und -Protokollen sowie eigener Geschäftslogik, die aus verschiedenen Quellen stammen und in Build- und Release-Pipelines mit selbst geschriebenen Code zusammengeführt werden. Sicherheitsprobleme können in jedem Bestandteil und an jedem Punkt in der Software-Lieferkette auftreten. Das setzt Firmen dem Risiko von Sicherheitsverletzungen aus.

Ein hohes Risiko. Tauchen Sicherheitslücken in Open-Source-Bibliotheken oder Anwendungen auf, wissen viele Verantwortliche nicht, ob und wie sie reagieren sollen. Die wenigsten Unternehmen verfügen über eine vollständige Liste der eingesetzten Anwendungen und aller darin integrierten Komponenten. Das kann zu einem großen Problem werden. Dies gilt insbesondere, wenn bei systemkritischen Anwendungen nicht klar ist, welche Komponenten sie enthalten und ob sie bekannte Sicherheitslücken aufweisen. Gänzlich auf Open Source zu verzichten kann kaum die Lösung sein. Zum einen ist Open Source generell nicht unsicherer als proprietäre Software, zum anderen enthält so gut wie jede proprietäre Software selbst Open-Source-Bestandteile. Das Problem an dieser Stelle ist denn auch weniger Open Source als vielmehr die fehlende Dokumentation der betreffenden Komponenten.

 

Software muss deutlich sicherer werden

Ein Beispiel ist die Lücke in der Open-Source-Java-Bibliothek log4j. Viele Unternehmen sind sich nicht oder nicht ausreichend bewusst, dass sie diese Bibliothek in ihren Anwendungen einsetzen und können folglich nicht angemessen reagieren. Dadurch entsteht ein enormes Sicherheitsrisiko. Es lässt sich aber mittels einiger Vorgehensweisen senken, die wir nachfolgend beschreiben.

Open-Source-Projekte liefern naturgemäß einen hohen Grad an Transparenz. Allerdings lässt sich der Vorteil nur dann nutzen, wenn Verantwortliche im Unternehmen genau wissen, welche Open-Source-Komponenten im Einsatz sind. Dafür sind dringend europaweite Prüfstrukturen notwendig. Dieser Meinung ist auch BSI-Vizepräsident Gerhard Schabhüser. Er konstatiert, es gebe in Anwendungen deutlich zu viele Sicherheitslücken. Software sollte in Zukunft noch mehr nach einem Security-by-Design-Ansatz entwickelt werden. Dazu gehören Stücklisten für Anwendungen, welche die enthaltenen externen Software-Komponenten inventarisieren und verzeichnen, an welcher Stelle der Anwendung diese Komponenten eingesetzt werden. Nur so lassen sich Sicherheitslücken schnell und zuverlässig schließen. Wie wichtig das ist, bestätigen aktuelle Statistiken.

 

Stücklisten senken das Sicherheitsrisiko

Um die Applikationssicherheit weiter zu verbessern, sind Veränderungen in der Entwicklungs-Pipeline und beim Einsatz von Anwendungen notwendig. Das gilt für proprietäre Anwendungen, aber auch für Open-Source-Projekte. Hackerangriffe auf unsichere Anwendungen werden in Zukunft eher zu- als abnehmen, auch von staatlicher Seite. Der BSI-Lagebericht 2021 spricht schon im Oktober letzten Jahres von einer angespannten bis kritischen Bedrohungslage. Im Februar 2021 hat das BSI den höchsten jemals gemessenen Wert an neuen Schadprogramm-Varianten notiert. Pro Tag kamen durchschnittlich 553.000 neue Varianten hinzu. Insgesamt wurden im Berichtszeitraum 144 Millionen neue Schadprogramm-Varianten gezählt, ein Plus von 22 Prozent gegenüber dem Vorjahreszeitraum. Auch die Qualität und die Verbreitung vieler gravierender Schwachstellen in IT-Produkten gibt Anlass zur Sorge. So wurde eine gravierende Schwachstelle in Microsoft-Exchange auf 98 % aller geprüften Systeme festgestellt. Nach einer repräsentativen Studie des Bitkom aus 2021 ist der deutschen Wirtschaft im Jahr 2020 ein Schaden von 220 Milliarden Euro durch kriminelle Cyberattacken entstanden, und das quer durch alle Branchen. Eine Verdopplung gegenüber dem Vorjahr.

Eine Stückliste von allen in einer Anwendung enthaltenen Komponenten erlaubt es den Verantwortlichen, zeitnah zu reagieren, wenn Sicherheitsupdates oder Aktualisierungen notwendig werden. Eine Stückliste kann auch Code-Bestandteile enthalten, die nicht von den Entwicklern einer proprietären Anwendung oder Open-Source-Lösung selbst entwickelt wurden.

 

Softwareanbieter sollten Stücklisten erstellen und Zeitpläne für das Beseitigen von Schwachstellen

Wer Software entwickelt und auf externe Komponenten setzt, sollte eine Liste der enthaltenen Komponenten führen und einen Zeitplan erstellen, gemäß dem Sicherheitslücken behoben werden können. Der Einsatz von Open-Source-Komponenten sollte also geplanter und vor allem maßgeblich unter Sicherheitsaspekten erfolgen.

Unternehmen und Organisationen, die Software kaufen oder abonnieren, sollten auf einer solchen Liste bestehen, die wie eine Art Beipackzettel funktioniert. Firmen kämpfen dann nicht wie bei log4j mit unbekannten Risiken, sondern können sich besser vorbereiten und schneller reagieren. Open-Source-Schwachstellen sind öffentlich zugänglich und werden von der Community relativ schnell geschlossen. Allerdings haben auch Angreifer Zugang zu diesen Informationen und nutzen sie gezielt für Angriffe aus. Dazu kommt, dass neue Funktionen und Fehlerbehebungen nicht bei allen Open-Source-Lösungen rechtzeitig Eingang finden. Kommen diese Komponenten dann noch in proprietärer Software oder in anderen Open-Source-Projekten zum Einsatz, lassen sich die Lücken nur schließen, wenn man über eine genaue Auflistung der enthaltenen Komponenten und Versionen verfügt.

 

Sicherheitslücken offen legen – zwangsläufig mit dem Risiko der Kriminalisierung verbunden?

Sicherheitslücken aufzudecken und vertrauensvoll offenzulegen, sollte im Interesse der Betroffenen sein. So könnte man wenigstens meinen. Eine Sicherheitsforscherin, die eine Lücke in der Wahlkampf-App der CDU gefunden und veröffentlicht hatte, sah sich aber zunächst mit einer (später zurückgezogenen) Anzeige konfrontiert. Ob Experten sich in Zukunft eher zurückhalten, gefundene Sicherheitslücken zu dokumentieren und zu veröffentlichen, bleibt abzuwarten. Für die Zukunft einer sicheren Softwareentwicklung wäre es jedenfalls alles andere als ideal. Grundsätzlich muss natürlich gewährleistet sein, dass das Aufdecken und Melden von Sicherheitslücken sowie die Verwendung der Stücklisten rechtlich korrekt sind. Es sollten keine juristischen Probleme entstehen, wenn Sicherheitslücken in Komponenten (auch in proprietären Anwendungen) offen gelegt werden. Hier sollte der Gesetzgeber aktiv werden und Sicherheitsforscher eher unterstützen als die Entwicklung sicherer Software zu behindern. Wer Sicherheitslücken findet und meldet, sollte sich im Vorfeld dennoch besser juristisch beraten lassen.

 

Intelligente Pipelines für mehr Softwaresicherheit

Damit Anwendungen sicherer und die enthaltenen Open-Source-Komponenten zuverlässig aufgelistet, dokumentiert und gewartet werden können, sind intelligente Pipelines in der Softwareentwicklung notwendig. Die Applikationssicherheit (AppSec) ist nur durch Automatisierung realisierbar. Dadurch ist es möglich, Schwachstellen in der Anwendungsschicht aufzuspüren und deren Zahl zu senken.

Laut einer Umfrage aus dem Sommer 2021 verwenden inzwischen fast drei Viertel der befragten Unternehmen AppSec-Tools für mehr als die Hälfte ihrer Softwareprojekte. Zwei Drittel der Unternehmen setzen bereits umfassend auf automatisierte Application-Security-Test-Tools. Das funktioniert natürlich nur, wenn diese Tools und die Entwicklungs-Pipeline für DevOps-Umgebungen geeignet sind und sich in CI/CD-Pipelines optimal integrieren lassen. Richtig eingesetzt, können AppSec-Scanner in der Pipeline mitlaufen und durch richtige Filter und Priorisierung sicherstellen, dass alle eingesetzten Komponenten bezüglich Schwachstellen untersucht werden. Das spielt bei der Integration externer Open-Source-Bibliotheken und -Komponenten eine wichtige Rolle. Dies gilt ebenso bei der Entwicklung von Open-Source-Anwendungen. Auch hier sollten Lücken bereits während der Entwicklung behoben werden, nicht erst später durch die Community, wenn der Open-Source-Code bereits in einer Vielzahl weiterer Anwendungen integriert ist.

 

Sicherheit und Stabilität mittels DevSecOps

Um diese Herausforderung zu bewältigen, bieten sich intelligente Pipelines an. Sie ermöglichen eine zweckoptimierte Automatisierung und Orchestrierung der verschiedenen AppSec-Tools und -Aktivitäten. Gartner hat diese Vorgehensweise bereits 2019 als »Application Security Orchestration and Correlation« bezeichnet. Die intelligente Pipeline entscheidet, wann, wo und wie Tools zum Einsatz kommen sollen und was mit den Ergebnissen der Scans passieren soll.

Dazu kommen Richtlinien, welche die AppSec-Aktivitäten steuern und auch bei der Erstellung von »Beipackzetteln« für Software helfen können. Dieser Policy-as-Code-Ansatz fördert die Zusammenarbeit von DevOps-Teams zu einem umfassenderen DevSecOps-Ansatz. Sicherheit und Inventarisierung werden so zu einem Bestandteil der Pipeline – und nicht mehr als notwendiges Übel oder Entwicklungshemmnis empfunden. Im Rahmen von DevSecOps lässt sich zudem eine einheitliche Darstellung von Schwachstellen umsetzen. Dadurch können Stücklisten der enthaltenen Komponenten aufgebaut, vereinheitlicht und deren Lücken übersichtlich zusammengefasst werden. Das bringt die Integration von Open-Source-Komponenten auf einen sicheren und stabilen Stand. Ob mit oder ohne Orchestrierungs-Tools – wer seine Software sicherer machen will, muss zwangsläufig Überlegungen dazu anstellen, welche AppSec-Aktivitäten zu welchem Zeitpunkt Sinn machen.

Lucas v. Stockhausen, Senior Director Solutions and Sales Engineering Synopsys