Mehr Sicherheit für die Software-Lieferkette Die unverzichtbaren Schritte

Heutzutage gibt es vielfältige Bestrebungen und Initiativen, um die Sicherheit der Software-Lieferketten langfristig zu verbessern. Ein Ansatz ist die Verwendung von generativer KI/Large Language Models (LLMs). Parallel dazu wurden Gesetzesvorlagen und Regularien auf den Weg gebracht, die auch die Sicherheit der Lieferketten betreffen. Denn wer in der Produkt-, Organisations- oder Produktentwicklung beschäftigt ist, der ist auch gefordert, die Authentizität und Integrität von allem nachzuweisen, was erstellt wird.

Eine „Software-Lieferkette“ umfasst alle Menschen, Prozesse und Technologien, die zum Schreiben, Erstellen, Bereitstellen und Verwenden einer Software eingesetzt werden. Also, jeden, der mit einer Software in Berührung kommt und mit der Erstellung der Prozesse betraut ist, die zum Lebenszyklus einer Software gehören.

Ebenso wie alle Technologien, ob intern oder extern, die dazu beitragen, eine Software korrekt zu entwickeln, einzusetzen und zu nutzen. Angesichts dessen wird schnell offensichtlich, wie ausgedehnt, die damit verbundene Angriffsfläche ist.

Die Sache mit der Sicherheit – und was Linux damit zu tun hat

Wenn man über die Sicherheit der Lieferkette spricht, bezieht sich dies auf den kompletten Lebenszyklus einer Software, von dem Moment an, in dem sie entsteht, bis zu dem Zeitpunkt, an dem sie tatsächlich eingesetzt und genutzt wird. Ganz gleich, ob es sich um eine milliardenschwere Idee handelt, die Sie auf eine Serviette notieren oder ob man beginnt, Code zu schreiben, um eine bestimmte Anforderung zu erfüllen.

Einige zentrale Fragen zu den Risiken, stellen sich gleich zu Beginn. Woher wissen wir, wer eine Software schreibt? Wie authentifizieren und verifizieren wir die Identität der jeweiligen Personen, die zu einer Software beitragen? Daran schließt sich die Frage an, ob wir diesen Personen tatsächlich vertrauen. Nur weil wir in der Lage sind, eine Identität zu überprüfen, heißt das nicht zwangsläufig, dass sie vertrauenswürdig ist. Und wenn, wie hoch ist der Grad der Vertrauenswürdigkeit?

Ein gutes Beispiel für dieses Konzept von Entwickler, Authentizität und Vertrauen ist die Linux-Community. Der Kernel steuert etliche der heute eingesetzten Systeme und Geräte – nicht immer ist den Benutzern das bewusst. Einige Forscher an der Universität von Minnesota (als Teil des Open-Source-Projekts Linux) nahmen den hohen Verbreitungsgrad von Linux zum Anlass für ein Experiment.

Sie versuchten selbst (diskret) Sicherheitslücken in Linux einzubauen, um zu testen, welche Folgen das haben würde. Insbesondere, weil Linux weltweit so populär ist. Im Laufe des Review-Prozesses kamen durchaus Bedenken aus der Community, schlussendlich wurden die Änderungen aber akzeptiert. Verständlicherweise war die Entwicklergemeinschaft nicht sonderlich erfreut, als die Universität den Schleier lüftete. So wenig, dass die Universität von Minnesota für die Zukunft von der Mitarbeit ausgeschlossen wurde. Hier wurde die Integrität durch die Community in Frage gestellt – trotz der bis dahin positiven Historie.

Wenn es um Impersonation und Identitätsmanagement geht, hat GitHub eine starke Position. Die Politik von GitHub besagt, dass jemandem die Mitarbeit versagt wird, wenn er eine falsche Identität angibt, wenn er/sie versucht, andere darüber zu täuschen, wer er/sie ist oder für welche Organisation er/sie arbeitet.

Ein weiterer wichtiger Punkt ist, dass Hacker und Forscher jetzt aktiv Entwickler ins Visier nehmen. Es ist bereits erwiesen, dass Hacker Social-Engineering-Angriffe nutzen und Entwickler gezielt angreifen. Etwa, um sich erweiterte Zugriffsberechtigungen zu verschaffen und so die Sicherheit der Lieferkette insgesamt zu schwächen. Dies ist ein Beispiel dafür, wie externe Bedrohungsakteure in der Lage sind, die Sicherheit der Lieferkette zu gefährden, indem sie direkt oder indirekt diejenigen ins Visier nehmen, die die Software schreiben.

Authentizität und Integrität der Entwickler

Für jedes System, mit dem ein Entwickler arbeitet, sollte man sicherstellen, dass starke Authentifizierungsanforderungen greifen, die den neuesten NIST-Vorschriften entsprechen. Dazu zählen beispielsweise Multi-Faktor-Authentifizierung oder Token-basierte Authentifizierungsmechanismen. Wenn es darum geht, die Integrität von Entwicklern zu überprüfen, wird es ein wenig schwieriger. Es gibt inzwischen einige Systeme, die auf Verhaltensanalysen basieren, um potenziell unzufriedene Mitarbeiter oder anormale Verhaltensweisen zu identifizieren.

Der nächste Schritt besteht darin, den Code für andere freizugeben. Dazu speist ihn der Entwickler in ein sogenanntes Quellcode-Repository ein, wie etwa GitHub. Anschließend kann jeder, der Zugang zu diesem System hat, mit der Überprüfung des Codes beginnen.

Ein weiterer wichtiger Punkt für die Sicherheit der Lieferkette: Wer darf sich an diesem System tatsächlich authentifizieren? Dies ist das Gehäuse für den gesamten Quellcode. Verzichtet man auf ein entsprechendes Authentifizierungsmanagement, kann sich jeder mit einem ausreichenden Netzwerkzugang den Quellcode der Produkte ansehen. Die Idee dahinter ist, dass möglichst viele Mitarbeitende Änderungsvorschläge, Patches oder sonstige Vorschläge einbringen. Das ist zwar edel im Geiste, aber gleichzeitig ein hohes Sicherheitsrisiko.

Ob es sich nun um Passwörter handelt, die in den Quellcode eingebettet sind, oder um geistiges Eigentum, wie die Methode selbst oder den zugrunde liegenden Algorithmus – all das ist verschlüsselt und könnte kompromittiert werden. Wenn es um diese Systeme und die gemeinsame Nutzung von Quellcode geht, sollte man unbedingt eine Authentifizierung und Zugangskontrolle für diese Code-Repositorien durchsetzen. Sobald der Quellcode freigegeben ist, wird dieser irgendwann akzeptiert und in den sogenannten Hauptzweig des Codes integriert.

Im Visier der Hacker – der Build-Prozess

Danach wird in den meisten Fällen ein Build-Prozess ausgelöst, bei dem die Software kompiliert wird. Um den Code zu kompilieren, werden Bibliotheken und Komponenten von Drittanbietern herangezogen. Anschließend führt man eine Reihe von Tests durch und baut die Build-Infrastruktur auf. Wenn es um Angriffe im Zusammenhang mit der Software-Lieferkette geht, ist sie wahrscheinlich am stärksten betroffen.

Allein schon deshalb, weil hier so viele verschiedene Prozesse ablaufen, welche die gesamte Produktionsumgebung betreffen. Statt einer gehärteten Umgebung handelt es sich dabei nicht selten um den Rechner eines Entwicklers, gesichert mit Benutzernamen und Kennwort. Für einen Angreifer mit internem Netzwerkzugang wäre es trivial, diese Build-Umgebung auszunutzen.

Ein weiteres wichtiges Thema bilden die sogenannten „Secrets“. Wenn die Build-Systeme laufen, beziehen sie Material von Dritten ein. Es handelt sich nicht um eine zentralisierte, isolierte, eigenständige Sache. Der Build-Server sendet an wer weiß wen im Internet, um Daten für die Erstellung der betreffenden Software abzurufen. Der Build-Server muss sich dazu an vielen Stellen authentifizieren. Es muss beispielsweise eine Verbindung zu AWS herstellen, und zwar irgendwo im Build-Server oder mit AWS-Anmeldeinformationen. Ein Hacker, der in der Lage ist, eine Build-Umgebung auszunutzen, kann solche Secrets möglicherweise ausspähen.

Eines der häufigsten Probleme mit der Sicherheit moderner Lieferketten betrifft die Komponenten von Drittanbietern. Wenn sie heute eine neue Anwendung erstellen, verwenden Entwickler Komponenten und Bibliotheken von Drittanbietern. In dem Moment, in dem man Code von jemand anderem in eine eigene Anwendung einbaut, erbt man die Sicherheitsrisiken dieses Codes – seien es Schwachstellen, seien es Lizenzrisiken. Zudem hat man wenig bis gar keinen Einfluss darauf, welche Codierungspraktiken zugrunde liegen.

Zusammengenommen ist die Build-Infrastruktur ein ebenso häufig genutztes wie ideales Ziel für einen Hacker. Dafür gab es in den letzten Jahren einige schlagzeilenträchtige Beispiele, einschließlich der bekannten Log4J-Schwachstelle. Anfällige Komponenten sind ein nicht zu unterschätzendes Risiko. Dazu kommen Bibliotheken und Komponenten, die absichtlich manipuliert werden.

Es gibt aber nicht nur Komponenten mit unabsichtlich eingeführten Schwachstellen. Immer häufiger manipulieren Hackern mutwillig Bibliotheken und Komponenten. Typo Squatting ist eine nach wie vor beliebte Methode. Dabei erstellt ein Angreifer eine Bibliothek mit einem Namen, der dem Namen einer populären Bibliothek sehr ähnlich ist. Dies geschieht in der Hoffnung, dass ein Entwickler versehentlich diesen Namen eingibt und so unbeabsichtigt die bösartige Version verwendet, herunterlädt und installiert. Die Gefahr kann aber auch von unzufriedenen Open-Source-Entwicklern selbst ausgehen, die beispielsweise Code absichtlich so verändern, dass eine Anwendung nicht mehr ordnungsgemäß arbeitet.

Und zu guter Letzt noch die „SolarWinds-Lücke“. Es ist zwar schon ein paar Jahre her, aber es ist wahrscheinlich die erste derart öffentlichkeitswirksame Schwachstelle innerhalb der Lieferkette. Letztendlich handelte es sich um eine anfällige Build-Infrastruktur, bei der ein Hacker in einen Build-Dienst eindringen und Schadsoftware in den Build-Prozess einschleusen konnte. So wurde mit jedem neu ausgeführten Build die Schadsoftware automatisch in das Endprodukt injiziert.

Eine der wichtigsten Reaktionen auf die Gefährdungslage innerhalb der Software-Lieferkette war sicherlich die Executive Order 14028: Improving the Nation’s Cybersecurity von US-Präsident Biden und die damit verbindliche Forderung nach einer SBOM – also einer Software Bills of Materials. Die Software-Stückliste ist der Gradmesser, mit dem Sie tatsächlich feststellen können, ob Sie diese Software-Komponente verwenden oder nicht.

Testen, Testen, Testen

In der Testphase wird die Qualitätssicherung einer Software durchgeführt. Das wirft die Frage auf, welche Tools man dazu verwenden will. Etwa das Static Application Security Testing (SAST) und die Software Composition Analysis (SCA). Bei der SAST handelt es sich um ein strukturelles Testverfahren, bei dem statische Inputs wie Dokumentation (Anforderungen, Aufbau und Spezifikationen) und Quellcode geprüft werden, um bekannte Sicherheitslücken zu finden. Das heißt, der Code lässt sich auf Schwachstellen hin überprüfen.

Demgegenüber stellt sich die Software Composition Analysis als ein Verfahren der Anwendungssicherheit dar, mit dem sich Open-Source-Komponenten schnell zurückverfolgen und analysieren lassen. Mit SCA prüft man also die Abhängigkeiten auf Sicherheitslücken. Beide Technologien zusammen unterstützen Sie dabei, Secrets im Quellcode zu erkennen, die beseitigt werden müssen, und anfällige Komponenten von Drittanbietern zu identifizieren.

Good to go? Die Bereitstellung einer Software

Jetzt ist die Software bereit, benutzt zu werden. Dazu wird sie üblicherweise auf ein anderes System übertragen, wo man sie herunterladen und anschließend verwenden kann. Eine der gebräuchlichsten Formen der Paketierung von Software sind heute Container. Wenn Sie jemals im Bereich der Lieferkette oder mit Entwicklungsteams in einer Cloud-Umgebung zusammengearbeitet haben, sind Sie wahrscheinlich mit Containern oder Docker vertraut.

Einer der wichtigsten Schritte, ist es, zu verifizieren, dass das, was freigegeben wurde, genau das Gleiche ist, was getestet wurde, und dies wiederum genau das Gleiche ist, das gebaut wurde. Hier wird die Integrität geprüft. So lässt sich feststellen, ob jemand Schadsoftware eingeführt oder die erstellte Version anderweitig verändert hat.

Das Wichtigste ist zu diesem Zeitpunkt, die Bereitstellungsinfrastruktur zu schützen. Dazu zählen Maßnahmen wie Authentifizierung, Zugriffskontrolle, Befolgen der NIST-Richtlinien und Implementierung der Integritätsüberprüfung, einschließlich von digitalen Signaturen, Code Signing und dergleichen.

Benutzen….

Zu guter Letzt soll es um die eigentliche Nutzung der Software gehen. Im Übrigen eine nicht selten vernachlässigte Phase beim Thema Sicherheit der Software-Lieferkette. Heute verfügen Browser über integrierte Mechanismen zur Überprüfung der Software wie etwa TLS. Wenn man keine rein Website-basierte Software verwendet und vertreibt, wird die Sache komplexer.

Dazu versetzt man sich am besten in die Lage eines Anwenders. Wie soll der Nutzer die Authentizität und Integrität der Software überprüfen? Woher soll ein Anwender letztendlich wissen, dass die Software, die er erworben hat, auch tatsächlich die Software ist, die wir installiert haben? Auch hier geht es offensichtlich darum, jeden Schritt in diesem Prozess zu überprüfen.

Dazu zählen Aspekte wie digitale Signaturen, Websites, Code und das Signieren. Zudem sollte der Benutzer darüber aufgeklärt sein, dass und wie er die Integrität einer Software überprüfen kann. Beispiele, wo das eher weniger gut funktioniert hat, gibt es einige. Auch wenn man sich nicht unbedingt die größten Sorgen machen muss, ob die eigene Fernbedienung zum Abhörgerät geworden ist, wie im RSAC-Forschungsbeispiel von Comcast. Festzuhalten bleibt, dass der Konsument einer Software nicht immer eine Person sein muss. Oft ist es ein physisches Gerät oder auch ein anderes Stück Software.

Gerade bei der Softwarenutzung und Integritätsprüfung, stößt man häufig auf gefälschte Websites, die Aktualisierungen anbieten, welche sich als Malware entpuppen. Das ist ziemlich häufig der Fall, etwa wenn smarte Fahrzeuge gehackt werden.

John Trest ist Chief Learning Officer bei der VIPRE Security Group.

VIPRE Security Group