Lieferkettensicherheit – und was es mit transienten Abhängigkeiten auf sich hat

Cybersecurity

Immer häufiger liest man von Angriffen auf die Software-Lieferkette. Dabei ist oft nicht klar, welche Lieferkette eigentlich gemeint ist und welche Abhängigkeiten bestehen. In einigen Fällen führt dies dazu, dass das Thema grundsätzlich ignoriert wird, wenn die eigene Lieferkette scheinbar nicht betroffen ist. Dabei sind die Angriffe auf Lieferketten so vielfältig wie diese selbst.

Udo Schneider, Security Evangelist Europe bei Trend Micro

Software regiert die Welt. Sie hält Flugzeuge am Himmel und Krankenhäuser am Laufen. Sie sorgt dafür, dass wir zuhause unterhalten werden und bei der Arbeit produktiv sind. Diese Allgegenwärtigkeit macht sie auch zu einem Schlüsselfaktor, wenn es darum geht, das Risiko in der technologischen Lieferkette zu bewerten. Denn heutige Software-"Produkte" sind meist keine Code-Monolithen, viel mehr sind sie eine Ansammlung von verschiedenen Teilen. Und jeder dieser Bausteine kann neue Risiken mit sich bringen. Zu verstehen, wo und warum es besteht, stellt den ersten Schritt zur Minderung dieses Risikos dar.

Abhängigkeiten von Abhängigkeiten

Kaum eine Anwendung wird heute noch von Grund auf neu entwickelt, ohne auf Bibliotheken Dritter (Open Source oder kommerziell) zurückzugreifen. Und was mit der Einbindung einiger weniger Bibliotheken beginnt, kann schnell zu sogenannten transienten Abhängigkeiten führen. Denn die selbst hinzugefügten Abhängigkeiten haben wiederum Abhängigkeiten und so weiter. So entsteht ein regelrechter Abhängigkeitsbaum.

Das ist deshalb ein Problem, da eine Schwachstelle in einer beliebigen Abhängigkeit die gesamte Anwendung, die sich auf sie stützt, angreifbar machen kann. Dies gilt auch für Schwachstellen, die ohne Verschulden des Entwicklers erst lange Zeit nach der Veröffentlichung bekannt werden. Das bekannteste Beispiel ist ein Fehler in Log4j, einem weit verbreiteten Logging-Framework für Java, der unter dem Namen «Log4Shell» bekannt und fast sofort ausgenutzt wurde. Da Log4j von mehr als 35’000 Java-Softwarepaketen verwendet wurde, ermöglichte die Schwachstelle die Remotecodeausführung in einer Vielzahl von Java-Anwendungen.

Ein weiteres Beispiel für die Komplexität der Software-Lieferkette sind Docker-Container. Aus Sicht der Lieferkette sind sie lediglich ein Verpackungsformat für Software. Aus Sicht der Abhängigkeiten enthalten sie jedoch eine Vielzahl von Drittanbieteranwendungen, Paketen, Betriebssystemtools, Container-Overlays und anderen Artefakten. Und wie bei direkten Bibliotheksabhängigkeiten kann eine Schwachstelle in einer dieser Komponenten die gesamte Anwendung gefährden. Nutzer haben es hierbei mit einem Abhängigkeitsbaum von unvorstellbarer Grösse zu tun.

Einem Bericht zufolge wurden im vergangenen Jahr jeden Monat 1,2 Milliarden anfällige Abhängigkeiten heruntergeladen, wobei sechs von sieben Sicherheitslücken in Projekten auf transitive Abhängigkeiten zurückzuführen waren.

Sichtbarkeit und Kontrolle erlangen

Der erste Schritt zur Risikominderung in solch massiven Abhängigkeitsstrukturen besteht darin, Transparenz zu schaffen. Aufgrund des Umfangs der Komponenten und der Komplexität der Daten muss dies automatisiert geschehen. Ähnlich wie Stücklisten in der physischen Welt werden Software-Stücklisten (Software Bills of Material, SBOMs) in der IT immer beliebter, um Abhängigkeiten zu erfassen.

Diese werden automatisch erstellt –- idealerweise innerhalb der CI/CD-Pipeline, da dies der einzige Ort ist, an dem Abhängigkeitsinformationen vollständig verfügbar sind. Wenn dies nicht möglich ist (z. B. bei Software von Drittanbietern oder Containern), ist es immer noch möglich, SBOM-Informationen aus dem "toten" Software-Artefakt zu extrahieren. Während kommerzielle Softwareanbieter momentan noch zögern, SBOMs zur Verfügung zu stellen, scheint es wahrscheinlich, dass sie zum Standard werden, insbesondere beim Einsatz in kritischen Umgebungen. In der Schweiz und der EU gibt es diese gesetzlichen Vorgaben noch nicht –- aber wenn man die Kommunikation und Arbeitsgruppensitzungen verfolgt, muss man davon ausgehen, dass dies auch hier früher oder später in der einen oder anderen Form verpflichtend wird –- zumindest für bestimmte Kunden-/Anwendungsbereiche.

Eine der bisher bekanntesten Einschränkung ist jedoch, dass SBOMs nur für die "gesperrte" Version von Abhängigkeiten exakt sind, so dass selbst kleine Versionsanpassungen SBOM-Informationen praktisch wertlos machen können. Dies ist kein Problem für Programmiersprachen und Paketmanager, für Docker-Dateien und Kubernetes-Manifeste ist es jedoch schwieriger.

Sobald die SBOM die Abhängigkeiten sichtbar gemacht hat, müssen Anwender diese kontinuierlich gegen bekannte Schwachstellen validieren. DependencyTrack von OWASP ist eines der bekanntesten Open-Source-Tools für diesen Zweck. Wenn also beispielsweise der nächste Log4Shell-ähnliche Vorfall auftritt, können Unternehmen auf einen Blick erkennen, wo und wie sie betroffen sind, und zwar für eine breite Palette von Produkten und Versionen.

Auf dem Weg zu DevSecOps

Die zunehmende Komplexität von Software-Lieferketten droht, die Fähigkeit der Unternehmen zu übersteigen, die Risiken in diesen Ketten zu verwalten. SBOMs und automatisierte Schwachstellenprüfungen können eine Antwort auf diese Herausforderung sein. Der Schlüssel für Unternehmen besteht darin, dieses Wissen und entsprechende Prozesse über DevSecOps in die Entwicklungszyklen einzubetten. Log4Shell hat gezeigt, dass das Worst-Case-Szenario manchmal Realität werden kann.