Abhängigkeiten von Abhängigkeiten: Die entscheidende Herausforderung beim Management des Software-Lieferkettenrisikos

Software regiert die Welt. Es hält Flugzeuge in der Luft, Krankenhäuser am Laufen und stellt sicher, dass das globale Finanzsystem nie aus der Fassung kommt. Doch zunehmend werden diese Anwendungen mit Open-Source-Codekomponenten aus verschiedenen unterschiedlichen Quellen erstellt. Komplexität ist die neue Normalität, egal ob es sich um proprietäre Software oder maßgeschneiderte, selbst entwickelte Apps handelt. Und Komplexität ist der Feind der Sicherheit.

Die komplexen Beziehungen zwischen Komponenten und die Leichtigkeit, mit der Bedrohungsakteure Malware in Upstream-Code einfügen können, sollten Sicherheitsmanagern Anlass zur Sorge geben. In den letzten Jahren häuften sich die Weckrufe. Es ist Zeit, einen effektiven Weg zu finden Verwaltung der Software-Lieferkette Risiko.

Wie die Software-Lieferkette funktioniert

Lieferketten sind die entscheidenden Wege, über die Rohstoffe und Komponenten geleitet werden, bevor sie zusammengebaut, verkauft und verwendet werden. In der digitalen Welt stellt man sich solche Komponenten oft besser als Dienstleistungen vor, die vom Lieferanten an den Kunden erbracht werden. Als wir in einem früheren Artikel diskutiert, sind diese Dienstanbieter ein immer beliebteres Angriffsziel, da Bedrohungsakteure einen guten ROI generieren können. Wenn Sie einen Geschäftsprozess-Outsourcer oder einen IT-Dienstleistungsriesen angreifen, besteht die Möglichkeit, Daten von einem potenziell großen Pool nachgelagerter Kunden zu stehlen und/oder zu erpressen.

Eine Software-Lieferkette ist ähnlich, aber in diesem Fall umfasst das System die Komponenten, Codebibliotheken, Tools und Prozesse, die zum Erstellen von Software erforderlich sind. Durch die Kompromittierung einer einzelnen Komponente oder sogar einer gesamten Anwendung können Angreifer möglicherweise jeden Entwickler oder jede Organisation beeinträchtigen, die diese Software/Komponente verwendet.

Wo ist das Risiko?

Software regiert zwar die Welt, aber was genau steckt hinter der Entwicklung der Anwendungen, die alles antreiben, von E-Commerce-Plattformen bis hin zu kritischen Unternehmens-ERP-Systemen? Zunehmend handelt es sich um Open-Source-Komponenten. A Sonatype-Bericht schätzt, dass Entwickler allein im Jahr 2022 3.1 Billionen Anfragen für solche Komponenten aus den vier größten Open-Source-Ökosystemen gestellt haben: Java, JavaScript, Python und .NET. Der Vorteil besteht darin, dass Entwickler durch das Herunterladen dieser vorgefertigten Pakete die Markteinführungszeit verkürzen und dem Unternehmen helfen können, schneller auf die sich schnell ändernde Marktnachfrage zu reagieren. Es wird behauptet dass 80 % des Codes in modernen Anwendungen von bereits vorhandener Open-Source-Software stammen.

Die Herausforderung besteht darin, dass diese Komponenten – oder Open-Source-„Abhängigkeiten“ – oft Schwachstellen enthalten. Laut Sonatype wurden im vergangenen Jahr jeden Monat 1.2 Milliarden anfällige Abhängigkeiten heruntergeladen. Wenn sie unbeabsichtigt heruntergeladen werden, besteht die Gefahr, dass sie zu einem späteren Zeitpunkt von Bedrohungsakteuren ausgenutzt werden. Entsprechend der Linux FoundationDas durchschnittliche Anwendungsentwicklungsprojekt enthält 49 Schwachstellen in 80 direkten Abhängigkeiten.

Noch schlimmer sind indirekte oder transitive Abhängigkeiten, die laut Sonatype für sechs von sieben Projektschwachstellen verantwortlich sind. Diese Abhängigkeiten sind schwerer zu verfolgen, da es sich praktisch um die Bibliotheken und Pakete handelt, die direkte Abhängigkeiten aufrufen – mit anderen Worten: Abhängigkeiten von Abhängigkeiten. Daher ist es nicht sofort ersichtlich, dass eine bestimmte Anwendung sie verwendet. Dadurch können Schwachstellen unter einer zusätzlichen Verschleierungsebene verborgen werden.

Ein typisches Beispiel ist das Berüchtigte Log4j-Schwachstellen. Log4j ist ein wenig bekanntes, aber beliebtes Protokollierungstool, das von über 35,000 Java-Softwarepaketen verwendet wird. Ende Dezember 10.0 wurde ein Patch für eine kritische Schwachstelle (CVSSS 2021) im Tool veröffentlicht. Aufgrund der weit verbreiteten Verwendung im gesamten Java-Open-Source-Ökosystem war es für viele Organisationen jedoch äußerst schwierig, alle Instanzen von Log4j definitiv zu finden und zu patchen in ihrer Umgebung. Entsprechend Google, waren die meisten betroffenen Java-Pakete anfällig, da Log4j eine schwer zu findende transitive Abhängigkeit war.

„Je tiefer die Schwachstelle in einer Abhängigkeitskette liegt, desto mehr Schritte sind erforderlich, um sie zu beheben“, heißt es weiter.

Leider haben die Bedrohungsakteure keine Zeit damit verschwendet, den Fehler auszunutzen. Entsprechend VerizonIm vergangenen Jahr erfolgte ein Drittel (32 %) der Suche nach der Schwachstelle in exponierten Systemen in den ersten 30 Tagen nach der Veröffentlichung.

Neben der Herausforderung, Schwachstellen in Open-Source-Komponenten zu finden und zu beheben, stehen Unternehmen vor dem zusätzlichen Problem, dass Bedrohungsakteure Schadpakete in Open-Source-Repositorys veröffentlichen. Sonatype gibt an, im Jahr 633 einen jährlichen Anstieg solcher Pakete um 2022 % auf über 88,000 bekannte Fälle verzeichnet zu haben.

Eine weitere Bedrohung: proprietäre Software

Das Risiko der Software-Lieferkette beschränkt sich jedoch nicht nur auf Open Source. Proprietäre kommerzielle Produkte können Schwachstellen enthalten, die Angriffe ausnutzen könnten und regelmäßig tun. Sie können auch Buggy enthalten Open-Source-Komponenten und -Tools, wie Log4j. Tatsächlich kann nur sehr wenig Code, der heute existiert, wirklich als „proprietär“ bezeichnet werden, so Steve Poole, Director of Developer Advocacy bei Sonatype.

„Infolgedessen haben Verbraucher scheinbar proprietärer Anwendungen ein falsches Sicherheitsgefühl und können daher unwissentlich anfällig sein“, sagt er gegenüber ISMS.online.

Bei ausgefeilteren Angriffen wie die SolarWinds-Kampagnekönnen Bedrohungsakteure sogar die eigene IT-Umgebung des Anbieters gefährden und Malware in legitime Software-Updates einschleusen. Dies ermöglichte es russischen Staatsbeamten, mehrere US-Regierungsbehörden zu kompromittieren.

„Jede Art von Software kann kompromittiert werden. Das Hauptproblem ist ein ungerechtfertigtes implizites Vertrauen in diese Software“, argumentiert Udo Schneider, Security Evangelist Europe bei Trend Micro.

Samuel Barfoot, Leiter des Sicherheitsteams bei Checkmarx, sagt, dass die Reife des Softwareanbieters und die ISO-Akkreditierung von entscheidender Bedeutung sind.

„Während die Software selbst möglicherweise nicht darauf ausgelegt ist, Schaden anzurichten, kann sie, wenn sie infiltriert wird, dazu verwendet werden, Informationen preiszugeben“, sagt er gegenüber ISMS.online. „Beim Wechsel in die Cloud sind Unternehmen auch Risiken im Zusammenhang mit Anbieterkontrollen, Support, Backups und Systemverfügbarkeit im Falle eines Hacks oder Ausfalls ausgesetzt. Die Reife des Anbieters ist entscheidend, um diese Risiken durch Vorbereitung und Vorkehrungen zu mindern.“

Transparenz ist der erste Schritt zum Risikomanagement

Unabhängig davon, ob es sich um proprietären oder Open-Source-Code handelt, müssen Unternehmen, die Risiken in der Software-Lieferkette mindern wollen, zunächst Einblick in „schlechte“ Komponenten und Unterkomponenten gewinnen, so Schneider von Trend Micro. Dies kann durch die Anforderung einer Software-Stückliste (SBOM) erreicht werden.

„Eine SBOM für ein Software-Artefakt (Bibliothek, ausführbare Datei oder sogar Container) enthält ein Abhängigkeitsdiagramm, in dem alle verwendeten Software-(Unter-)Komponenten aufgelistet sind, einschließlich einer genauen Versionsnummer.“ SBOMs können direkt aus der Quelle innerhalb eines generiert werden CI / CD-Pipeline oder später „tote“ Artefakte wie ausführbare Dateien oder sogar Container“, erklärt er. 

„Dies ist besonders hilfreich für proprietäre Software, bei der der Anbieter normalerweise keine SBOMs bereitstellt. In Rechtsgebieten/Branchen, in denen Anbieter eine SBOM bereitstellen müssen, können diese kontinuierlich auf bekannte Schwachstellen überprüft werden, was eine aktuelle Grundlage für mögliche Maßnahmen bietet.“

Poole von Sonatype fügt hinzu, dass Unternehmen auch die Sicherheitslage der Anbieter bewerten und dabei besonders auf die Qualität ihrer Prozesse zur Schwachstellenberichterstattung achten sollten. 

Für Open-Source-Komponenten sollten Organisationen ein Programm zur kontinuierlichen Evaluierung von Open-Source-Komponenten durchführen und bei Bedarf umgehend Patches/Updates durchführen, um eine schnelle Ausnutzung zu verhindern, argumentiert er. SCA-Tools (Software Composition Analysis) können ebenfalls hilfreich sein, indem sie herausfinden, was in Produkten oder Komponenten enthalten ist.

„Die Ausgereiftheit des SCA-Tools muss jedoch mit der der böswilligen Akteure mithalten und diese sogar übertreffen, sonst ist die Organisation dem tatsächlichen Risiko eines Angriffs über einen unentdeckten Vektor ausgesetzt“, warnt er. 

„Beziehen Sie schließlich die Entwickler mit ein, indem Sie sie darüber aufklären, wie moderne Cyber-Angriffe ablaufen und was sichere Codierungsprinzipien sind, und sie über ihre Verantwortung am Anfang der Software-Lieferkette aufklären – ihre unmittelbaren Entscheidungen und Handlungen haben Konsequenzen.“

Beginnen Sie mit einem ISMS

Schneider von Trend Micro argumentiert, dass ein Informationssicherheits-Managementsystem (ISMS) kann eine hervorragende Möglichkeit sein, Risiken in der Software-Lieferkette kontinuierlich zu mindern.

„Durch die Einspeisung von Daten aus SBOM-Tools, angereichert mit Verteilungsdaten, in ein ISMS ist es möglich, die Sicherheitslage und damit das Gesamtrisiko des gesamten Systems, von dem Software nur ein Teil ist, besser einzuschätzen und zu dokumentieren“, erklärt er. „Als Grundlage für die Risikominderung und die Dokumentation der ergriffenen Maßnahmen bietet dies im Prinzip eine weitaus bessere Sicherheit als die manuelle Nachverfolgung von Software-Assets.“

Eine Checkliste für das Risikomanagement in der Software-Lieferkette:

1. Fordern Sie eine SBOM an
2. Bewerten Sie proprietäre Softwareanbieter (insbesondere deren Schwachstellenberichte)
3. Nutzen Sie SCA-Tools, um Einblicke in Softwarekomponenten zu gewinnen
4. Suchen Sie kontinuierlich nach Schwachstellen und beheben Sie diese umgehend
5. Informieren Sie Entwickler über die Bedeutung von Security by Design
6. Erwägen Sie die Einspeisung von SBOM-Daten in ein ISMS für ein ganzheitliches Risikomanagement

Erfahren Sie, wie die ISMS.online-Lösung einen einfachen, sicheren und nachhaltigen Ansatz für das Risikomanagement und Informationsmanagement der Lieferkette mit ISO 27001 und über 100 anderen globalen Frameworks ermöglicht.

Sprich mit einem Experten