Thought Leadership
Innovationen sind ohne Open Source Libraries nicht mehr denkbar, denn Open Source verspricht schnelle und flexible Veränderung von Anwendungen. Wie stehen Entwickler aber zum Thema Sicherheit bei Open Source?
Im Folgenden stellt Julian Totzek-Hallhuber, Solution Architect bei Veracode, die wichtigsten Ergebnisse vor und geht darauf ein, welchen Zusammenhang es zwischen Corona-Warn-App, Open Source, Sicherheit und gefälschten Impfzertifikaten gibt.
Dank der Corona-Warn-App ist Open Source in aller Munde. Externen war es gelungen, einen QR-Code nachzubauen und damit Impfzertifikate zu fälschen. Dies hatte weitreichende Folgen. Bis die Sicherheitslücke behoben war, stellten Apotheken keine Impfzertifikate mehr aus. Lag der Fehler in der Anwendung? Waren die Open-Source-Komponenten der Applikation, die unter einer Apache-Lizenz vollständig zugänglich sind, unsicher? Die Antwort lautet nein, da sich die Schwachstelle bei der Corona-Warn-App durch einen logischen Fehler in der App erklären lässt, nicht durch einen Mangel an Anwendungssicherheit. Das Problem war letztendlich, dass keine Plausibilitätsprüfung der Zertifikate im Hintergrund erfolgte. Das Thema hat jedoch dazu geführt, dass Open Source und Sicherheit breit diskutiert werden.
Beständig ist die Veränderung
Einen umfassenden Überblick über Sicherheit und Open Source bietet der aktuelle SoSS v11: Open Source Edition. Für den Report hat Veracode 13 Millionen Scans von mehr als 86.000 Repositories mit mehr als 301.000 Bibliotheken analysiert. Zusätzlich wurden fast 2.000 Entwickler befragt, um einen umfassenden Überblick über die Sicherheit im Open-Source-Bereich zu erhalten und deren Arbeitsweise besser zu verstehen. Eine zentrale Erkenntnis: Die Open-Source-Welt wandelt sich unfassbar schnell. Was heute noch sicher ist, kann es morgen schon nicht mehr sein. Darauf müssen sich Entwickler bewusst einstellen. So zeigt der Report starke Schwankungen bezüglich der Sicherheit verschiedener Libraries in unterschiedlichen Programmiersprachen zwischen 2019 und 2020. Während .NET (System.Text.RegularExpressions), Go (/x/text), JavaScript (lodash), Java (jackson-databind), Python (urllib3) und Swift (nanopb) im Vergleich zum Vorjahr weiterhin die höchste Sicherheitsanfälligkeit aufweisen, veränderten sich die Programmiersprachen PHP (zendframework/zendframework1) und Ruby (rack) im gleichen Zeitraum deutlich. Beide stehen im Jahr 2020 an der Spitze der Rangliste der Sicherheitsrisiken, wobei sie im Vorjahr jeweils noch an dritter (rack) und siebter (zendframework/zendframework1) Stelle lagen.
Der Status Quo der Sicherheit bei Open Source Libraries – woher kommen die Risiken?
Entwickler agieren in einem sich ständig wandelnden Umfeld. Gleichzeitig updaten sie Open-Source-Libraries in 79 Prozent der Fälle nicht mehr, nachdem sie diese in ihre Codebase integriert haben, wodurch potentielle Sicherheitsrisiken entstehen. Erfreulicherweise können Entwickler Schwachstellen aber schnell beheben und das Risiko mindern, wenn sie genaue Kontextinformationen darüber erhalten, wie sich eine Schwachstelle auf die Sicherheit einer Anwendung auswirkt. Sobald Entwickler auf gefährdete Bibliotheken aufmerksam gemacht werden, beheben sie 17 Prozent der Schwachstellen innerhalb einer Stunde und 25 Prozent der Schwachstellen innerhalb einer Woche. Ohne diese Informationen, benötigen Entwickler oftmals mehr als sieben Monate, um 50 Prozent der bestehenden Schwachstellen zu beheben – diese Zeitspanne verkürzt sich bei vorliegenden Informationen jedoch drastisch auf nur drei Wochen. Unternehmen müssen daher in Zukunft einen umfassenden Informationsfluss zwischen Sicherheits- und Entwicklerteams priorisieren.
Ein „Set-and-Forget“ Mindset ist nicht genug
Die gute Neuigkeit ist, dass die meisten Sicherheitsupdates geringfügig sind und nur selten einen hohen Arbeitsaufwand für Entwickler darstellen. Tatsächlich können 92 Prozent der analysierten Schwachstellen innerhalb einer Bibliothek bereits mit einem Update behoben werden, wobei 69 Prozent davon höchstens eine kleine Versionsänderung oder weniger erfordern. Diese Updates beeinträchtigen selbst die Funktionalität der komplexesten Anwendung nicht, was bedeutet, dass die Behebung bestehender Schwachstellen zu einer weitaus weniger anstrengenden Aufgabe wird, wenn Entwickler ihr Mindset dahingehend ändern, dass sie die Sicherheit als kleines Element des Softwareentwicklungszyklus und nicht als Herausforderung betrachten.
Auch bei der Auswahl der Bibliotheken deckt der SoSS v11 Optimierungsbedarf auf Seiten der Entwickler auf. Lediglich 52 Prozent der befragten Entwickler verfolgen einen formalen Prozess bei der Auswahl von Libraries von Drittanbietern. Zusätzlich sind sich mehr als ein Viertel (28,4 Prozent) unsicher, ob es überhaupt einen formalen Prozess innerhalb ihres Unternehmens gibt. Von den Entwicklern, die einen formalen Prozess bei der Auswahl der Libraries verfolgen, geben 67,1 Prozent an, dass Funktionalität immer eine Priorität sei. 62,5 Prozent nennen Lizenzierung als Priorität, und Sicherheit steht für lediglich 52,5 Prozent immer an oberer Stelle.
Es ist eindeutig, dass Open-Source-Bibliotheken eine Schlüsselrolle bei der Beschleunigung der Softwarebereitstellung spielen – aber leider gibt es in den Anwendungen, die wir täglich nutzen immer wieder einige Sicherheitslücken, die behoben werden müssen. Der Druck, der auf den Entwicklern lastet, neue Apps so schnell wie möglich bereitzustellen, ist ein zentraler Aspekt in diesem Kreislauf der Unsicherheit – aber Entwickler müssen sich im Klaren sein, dass die Behebung dieser Schwachstellen die Bereitstellung von Anwendungen nicht verlangsamen muss. Regelmäßige Scans, die Beobachtung von Trends und die Zusammenarbeit mit Sicherheitsexperten, um die von den Entwicklern benötigten Information zu erhalten, tragen dazu bei, den Fehlerbehebungsprozess zu beschleunigen und eine ebenso sichere wie innovative Zukunft zu gewährleisten.
