Software-Lieferketten weiterhin im Fokus von Cyberkriminellen

Software-Lieferketten sind aktuell eines der wichtigsten und meistdiskutierten Themen im Bereich der Anwendungssicherheit. Angriffe auf die Supply Chain haben an Zahl und Umfang deutlich zugelegt. Dieser Befund hat staatliche Stellen und Regierungsbehörden auf den Plan gerufen, und es wurden eine Reihe neuer Vorgaben für die Supply Chain erlassen oder doch wenigstens auf den Weg gebracht.

Die verheerenden Auswirkungen einiger dieser Angriffe haben die Software Security-Branche teils in helle Aufregung versetzt, und auch hier wird eifrig an der Erstellung neuer Richtlinien gearbeitet.

Jeder, der mit Software arbeitet oder im weitesten Sinne damit zu tun hat, ist vermutlich schon mit sicherheitsrelevanten Aspekten der Supply Chain in Berührung gekommen. Will man das Wesen der Software-Lieferkette sowie die potenziellen Risiken und deren Auswirkungen verstehen, empfiehlt es sich, etwas genauer hinzuschauen.

Dazu muss man wissen, wie moderne Anwendungen heute üblicherweise entwickelt werden. Bei der Entwicklung von Applikationen greifen Softwareingenieure mit ziemlicher Sicherheit auf Drittanbieter-Software zurück. Die ist zumeist in ein „konsumierbares“ Format gepackt, um den Entwicklungsprozess zu beschleunigen oder zu optimieren. Solche Pakete von Drittanbietern werden oft als Komponenten, Anhänge, Bibliotheken oder Frameworks bezeichnet. Der Einfachheit halber soll hier der Begriff der „Komponente“ verwendet werden.

Man kann sich die Software-Lieferkette als die Gesamtheit aller Komponenten von Drittanbietern, Menschen, Prozessen und Technologien vorstellen. Sie alle sind an der Erstellung, Bereitstellung und Nutzung einer Software für eine Anwendung beteiligt. Daraus leitet sich eine Reihe von Fragen ab: Wer hat das Programm geschrieben? Woher stammen die einzelnen Komponenten? Woher wissen wir, dass der genehmigte Software-Build tatsächlich derjenige ist, der für einen Kunden freigegeben wurde? Wie kann ein Kunde dies überprüfen, bevor er die jeweilige Anwendung im Produktivbetrieb nutzt?

Komponenten von Drittanbietern zu verwenden hat naturgemäß viele Vorteile. Aber wie so oft ist da auch die Kehrseite der Medaille. Unabhängig von der eigenen Position oder dem technischen Background fallen wahrscheinlich jedem etliche Dinge ein, die schief gehen können, wenn Anwendungen von Drittanbieter-Komponenten abhängig sind:

• Wenn man eine Anwendung um die Komponente eines Drittanbieters herum aufbaut, schafft man sich dann automatisch eine Art von Anbieter oder Technologieabhängigkeit?
• Stellt der Händler einer DrittanbieterKomponente ausreichend Wartung oder Support zur Verfügung?
• Welche Auswirkungen hat das auf die Lizenzvergabe?
• Was passiert, wenn eine Sicherheitslücke auftritt?
• Inwiefern sind Kunden/Nutzer davon betroffen, und wie erfahren sie davon?
• Wie können sie Sicherheitslücken finden und schließen?
• Wer ist für die Sicherheitslücke verantwortlich?

Eine Liste, die sich beliebig fortsetzen ließe. Jeder einzelne Aspekt markiert ein erhöhtes Risiko für die betreffenden Anwendungen, deren Nutzer und für Unternehmen insgesamt.

Finden Sie den Fehler

Für diejenigen, die mit dem Bereich der Softwareentwicklung vertraut sind, halten wir noch eine weitere Herausforderung bereit:

Die folgende Textdatei deklariert die Verwendung mehrerer Komponenten von Drittanbietern in einer Maven-basierten Anwendung. Welche Zeile oder welche Zeilen des Codes repräsentieren eine Schwachstelle in der Software-Lieferkette?

Die Verwendung einer Drittanbieter-Komponente in diesem Abschnitt birgt ein besonders hohes Risiko. Haben Sie den Fehler gefunden?

In den Zeilen 15 und 31 wird die Verwendung einer anfälligen Komponente eines Drittanbieters namens „log“ deklariert. Eine Sicherheitsschwachstelle, die so schwerwiegend war, dass sie buchstäblich „das Internet lahmlegte“.

Damit man herausfinden kann, welche Art von Komponenten in einer bestimmten Anwendung enthalten sind, werden Komponenten von Drittanbietern normalerweise in einer Textdatei deklariert. Sie liegt dem Quellcode der Anwendung bei. Stößt ein Nutzer in seiner Anwendung auf eine solche Komponente, kann er getrost davon ausgehen, dass die betreffende Applikation und der Host bereits gefährdet sind.

Was ist dann zu tun? Die Liste sämtlicher Drittanbieter-Komponenten kann schon für eine einzelne Anwendung ziemlich umfangreich sein. Hier den Überblick zu behalten ist für Nutzer kaum möglich. Im Idealfall arbeiten IT- und Sicherheitsabteilungen an dieser Stelle deshalb mit der Software Composition Analysis (SCA). Mit diesem Testverfahren lassen sich riskante Komponenten in einer Anwendung identifizieren. Die SCA-Technologie wurde entwickelt, um den Quellcode und die Infrastruktur einer Anwendung zu analysieren und ein Inventar aller verwendeten Drittanbieter-Komponenten zu erstellen. Viele vergleichen dieses Inventar von Drittanbieter-Komponenten mit einer Datenbank bekannter ausnutzbarer Schwachstellen, wie z. B. der MITRE CVE-Liste. In diesem Bereich gibt es eine Vielzahl von SCA-Anbietern, solche, die ihre Tools kostenlos anbieten, Open Source-Lösungen bis hin zu kommerziellen Alternativen, die viele zusätzliche Funktionen und Einsatzmöglichkeiten bieten.

Was die Sicherheit der Software-Lieferkette anbelangt, kommt es vor allem auf die Authentizität und Integrität von Menschen, Prozessen und Technologien innerhalb der Anwendungsinfrastruktur an. Das Thema ist hinreichend komplex. Man kann es sich aber leichter machen, wenn man es im Kontext des Lebenszyklus der Softwareentwicklung betrachtet. Insbesondere der Entwicklungsphase, in der die Software geschrieben wird, der Erstellungsphase, in der die Software verpackt wird, und schließlich der Bereitstellungsphase, in der die Software freigegeben und genutzt wird. Für jede Phase des SDLC gibt es geeignete Testmethoden, um die Integrität einer Software und der Daten zu gewährleisten. Tools allein reichen aber nicht aus. Es geht auch darum, einen entwicklerfreundlichen Sicherheitsrahmen zu schaffen. Nicht zuletzt durch geeignete Trainingsmethoden, die Diskussionen aufwerfen, wichtige Erkenntnisse zusammenfassen und im Idealfall Checklisten für grundlegende Sicherheitskontrollen bereithalten.

Sicherheitsfachleute und Entwickler kämpfen gleichermaßen mit der Komplexität des Themas und den potenziell weitreichenden Auswirkungen auf alle Bereiche der Software-Lieferkette. Angesichts dessen sollten Entwicklungsteams besser als bislang in die Lage versetzt werden, geeignete Maßnahmen zu ergreifen, um die Risiken zu jedem Zeitpunkt im SDLC in den Griff zu bekommen.

Autor: Steffen Friis, VIPRE Security Group

vipre.com/de