Thought Leadership
Softwareentwicklung ist grundsätzlich eine gemeinschaftliche Anstrengung. Zwar fügt jedes Unternehmen, vom Startup bis zum Großunternehmen, seine eigenen Ingredenzien hinzu, schon allein, um das eigene Produkt von der Masse abzuheben. Eines aber eint sie alle: Entwickler sind fast durchgängig auf große Mengen an Fremdsoftware angewiesen.
Um mit der ständig steigenden Softwarenachfrage Schritt zu halten, greifen Unternehmen zunehmend auf Code aus Open Source Software zurück. Man geht inzwischen davon aus, dass Projekte wie Apache, Linux, Jenkins und viele, viele andere zwischen 85 bis 97 % der Codebasis der meisten Softwareprodukte ausmachen. Kommerzielle Softwareprodukte von Microsoft, Oracle und anderen Anbietern spielen ebenfalls eine wichtige Rolle im Software-Ökosystem.
Softwarekomponenten von Dritten bieten leistungsstarke Funktionen, die Entwicklern Zeit sparen und es ihnen erlauben, sich auf die Kernelemente ihrer Produkte zu konzentrieren.
Unternehmen in der Pflicht: Die Software-Lieferkette besser schützen
Wie wir beim jüngsten SolarWinds-Hack und davor beim Exploit von Apache Struts in Zusammenhang mit der Datenschutzverletzung bei Equifax beobachten konnten, ebnet anfällige Fremdsoftware den Weg zu ansonsten gut geschützen Zielen.
Angreifer, die sich aus dem gesamten Spektrum von staatlichen Elite-Hackern bis hin zu einer Vielzahl von kriminellen Gruppen rekrutieren, suchen ständig nach neuen Schwachstellen innerhalb der Softwarelieferkette. Es geht also nicht darum, das Ziel direkt anzugreifen, sondern über eine Schwachstelle in einem ansonsten vertrauenswürdigen Teil der Software Zugriff auf das Netzwerk zu erlangen.
Unternehmen, unabhängig von ihrer Position in der Lieferkette, entwickeln inzwischen zunehmend ein Verständnis dafür, dass Kunden eine sichere Software erwarten. Das heißt auch, dass Firmen die Verantwortung für die Sicherheit des Codes übernehmen, der aus Quellen Dritter kommt. Die Verantwortung endet also nicht bei der eigenen Entwicklung.
Letztendlich kann es einem Kunden zu Recht gleichgültig sein, ob eine Schwachstelle beim Softwareanbieter selbst liegt, oder an irgendeiner Stelle innerhalb der betreffenden Lieferkette. Für den Kunden hat es Priorität, dass der Anbieter die notwendigen Schritte unternimmt, um Sicherheit zu gewährleisten.
Fairerweise muss man allerdings einräumen, dass es alles andere als einfach ist, sich vor Supply-Chain-Angriffen zu schützen.
Drei Kernprobleme der Supply-Chain-Sicherheit
Unabhängig davon, ob Sie eine Fremdsoftware für die Entwicklung ihrer eigenen Produkte nutzen oder selbst die Systeme betreiben, auf denen die Software nach der Bereitstellung läuft – Unternehmen stehen vor erheblichen Problemen, was die sichere Nutzung von Software anbelangt. Viele Schwachstellen sind zudem mit Standardtools zum Testen der Anwendungssicherheit kaum zu finden.
Mangelnde Transparenz, mangelndes Verständnis
Viel zu viele Unternehmen wissen nicht genau, was in der Software steckt, die sie ganz selbstverständlich einsetzen. Im Falle von Open Source Software ist es unter Entwicklern gängige Praxis, Komponenten aus Repositories zu integrieren. Je nach dem, welche Funktion gerade gebraucht wird. Das Problem ist, dass sich oftmals nicht nachvollziehen lässt, welche Komponenten verwendet worden sind. Auf dieser Basis ist es schwierig, anfällige Software aufzuspüren und neu entdeckte Schwachstellen zu patchen. Hacker hingegen betrachten neu zugewiesene CVEs in populären Komponenten von Drittanbietern als ihre persönliche Eintrittskarte zum großen Zahltag.
Versteckte Abhängigkeiten
Aber selbst wenn Unternehmen nachverfolgen, welche Open Source-Komponenten verwendet werden, gibt es oft viele weitere unter der Oberfläche. Gerade Open Source-Komponenten werden ständig geforkt und in unterschiedlichen Projekten bei der Softwareentwicklung verwendet. Daduch entsteht ein Vielzahl von Ebenen. Es ist leider relativ unwahrscheinlich, dass Entwickler sämtliche Abhängigkeiten innerhalb all dieser Codeebenen kennen. Das Problem ist, dass sich in diesen Abhängigkeiten möglicherweise Schwachstellen verbergen. Und die lassen sich ausnutzen, wenn ein Angreifer eine solche Komponente ausmacht.
False Positives
Unternehmen werden von irrelevanten Schwachstellenalarmen bei Third-Party Software regelrecht überflutet. Aber selbst, wenn es sich um einen berechtigten Hinweis auf eine Schwachstelle handelt, muss die noch nicht zwingend ganz oben auf der Prioritätenliste stehen. Bei weitem nicht jede Softwarefunktion (das gilt insbesondere für Open Source-Komponenten) wird tatsächlich von einem proprietären Produkt aufgerufen. Schwachstellen-Scans werden jedoch unweigerlich alles aufdecken, was sie finden. Unabhängig davon, ob die Schwachstellen noch aktuell sind oder nicht. Selbst wenn es sich um einen berechtigten Alarm handelt, muss er nicht zwangsläufig sofort bearbeitet werden.
Updates und Patches einzuspielen ist so wichtig wie zeitaufwändig. Fehlalarme wirken sich nachteilig aus, wenn man seine Software effizient absichern will. Wenn man nur die Schwachstellen beseitigt, die tatsächlich aufgerufen werden, trägt das dazu bei, die Abläufe zu optimieren.
Asaf Karas, CTO und Mitgründer von Vdoo
