7 Risiken, die von Open-Source-Software ausgehen, und wie Sie sich dagegen schützen können
Was ist Open-Source-Software?
Viele Unternehmen und Produkte, Schätzungen zufolge 90 %, verwenden mindestens eine Open-Source-Komponente - auch wenn sie sich dessen nicht bewusst sind. Bei Open-Source-Software handelt es sich um Software, deren Code zur öffentlichen Einsichtnahme, Änderung und Verbesserung verfügbar ist. In der Regel wird diese Software in Zusammenarbeit mit einer Gemeinschaft erstellt und auf freiwilliger Basis gepflegt und aktualisiert.
Open-Source-Software kann unter einer Vielzahl von Lizenzen verwendet werden, je nachdem, was die Entwickler implementiert haben. Linux OS, Apache Web Server, WordPress und Mozilla Firefox sind nur einige der am häufigsten verwendeten Softwareprodukte.
Risiken bei der Verwendung von Open-Source-Software
Aufgrund des gemeinschaftlichen Aufbaus und der weitgehend unregulierten Verbreitung birgt die Verwendung von Open-Source-Software eine Vielzahl von Risiken, darunter auch einige Risiken für die Cybersicherheit.
1. Schwachstellen sind öffentlich bekannt
Sicherheitslücken in Open-Source-Software werden sowohl von den Mitwirkenden selbst als auch von Organisationen wie dem Open Web Application Security Project (OWASP) und der National Vulnerability Database (NVD) öffentlich bekannt gemacht.
Wenn Sie Teil der Community für ein bestimmtes Projekt sind, werden Sie oft vorgewarnt, bevor es an Gruppen wie OWASP und NVD weitergegeben wird, aber das gilt auch für alle anderen Mitglieder der Community. Das bedeutet, dass Sie sich Risiken aussetzen, wenn Sie bei der Pflege der neuesten Versionen oder der Aktualisierung von Komponenten nachlässig sind, da Schwachstellen häufig von Cyberkriminellen erkannt und ausgenutzt werden.
2. Mangelnde Sicherheit
Bei Open-Source-Software gibt es keine Ansprüche oder rechtlichen Verpflichtungen in Bezug auf die Sicherheit, und der Community-Support, der Sie darüber informiert, wie Sie die Software sicher implementieren können, ist möglicherweise nicht vorhanden. Die Entwickler, die für die Erstellung der Software verantwortlich sind, sind oft keine Sicherheitsexperten und wissen möglicherweise nicht, wie man Best Practices implementiert.
Obwohl Ressourcen wie die OWASP-Top-10- Liste der Sicherheitslücken öffentlich zugänglich sind und sich an Open-Source-Communities richten, enthalten sie nicht immer Anleitungen dazu, wie Sicherheitsfunktionen zum Schutz vor diesen Schwachstellen implementiert werden können.
Open-Source-Software enthält häufig Bibliotheken von Drittanbietern, die von Paketmanagern ohne Prüfung heruntergeladen werden, oder erfordert deren Verwendung. Der Blackbox-Charakter dieser Bibliotheken macht es schwieriger und zeitaufwändiger, etwaige Schwachstellen zu identifizieren und zu patchen, die sie möglicherweise enthalten.
3. Fragen zum geistigen Eigentum
Es gibt über 200 Arten von Lizenzen, die für Open-Source-Software gelten können, darunter Apache, GPL und MIT. Viele dieser Lizenzen sind untereinander nicht kompatibel, was bedeutet, dass bestimmte Komponenten nicht zusammen verwendet werden können, da bei der Nutzung von Open-Source-Software alle Bedingungen eingehalten werden müssen. Je mehr Komponenten Sie verwenden, desto schwieriger wird es, alle Lizenzbestimmungen im Blick zu behalten und miteinander zu vergleichen.
Einige Lizenzen enthalten "Copyleft"-Klauseln, die Sie verpflichten, jede Software, die mit den abgedeckten Komponenten erstellt wurde, vollständig als Open-Source zu veröffentlichen. Dies macht die Verwendung in proprietärer Software unmöglich und für kommerzielle Zwecke weniger attraktiv.
4. Fehlende Garantie
Für Open-Source-Software gibt es keine Garantien in Bezug auf Sicherheit, Support oder Inhalt. Obwohl viele Projekte unterstützt werden, werden sie von Freiwilligen durchgeführt und die Entwicklung kann ohne Vorankündigung eingestellt werden.
Die Community-Mitglieder bewerten die Software in der Regel auf Sicherheitsprobleme und bieten in offenen Foren Unterstützung an. Sie sind jedoch weder dazu verpflichtet noch haften sie für fehlerhafte Anleitungen.
Da Open-Source-Software von Gemeinschaften von manchmal anonymen Mitwirkenden erstellt wird, ist es schwierig zu überprüfen, ob der beigetragene Code original ist und nicht aus einer Drittquelle mit etablierten geistigen Eigentumsrechten stammt. In der Praxis bedeutet das: Wenn Sie Open-Source-Software verwenden, die Code mit verletzten Rechten enthält, können Sie für die Rechtsverletzung verantwortlich gemacht werden.
5. Entspannte Integrationsaufsicht
Teams haben oft unzureichende oder nicht vorhandene Überprüfungsprozesse, wenn es darum geht, welche Open-Source-Komponenten verwendet werden. Es kann sein, dass mehrere Versionen derselben Komponente von verschiedenen Teams verwendet werden oder dass die Entwickler sich nicht über widersprüchliche Funktionen oder Lizenzen im Klaren sind.
Diese Probleme können aufgrund mangelnder Kenntnisse der Software- oder Sicherheitsfunktionen, mangelnder Kommunikation zwischen Teams oder Teammitgliedern oder unzureichender oder fehlender Verfolgungs- und Dokumentationsprotokolle auftreten.
Im Gegensatz zu proprietärer Software von Drittanbietern, die über eingebaute Kontrollen verfügt, um die Verwendung mehrerer oder inkompatibler Versionen zu verhindern, sind Open-Source-Komponenten in der Regel darauf angewiesen, dass der Benutzer die ordnungsgemäße Verwendung überprüft.
6. Operative Unzulänglichkeiten
Die Verwendung von Open-Source-Komponenten kann eine Menge zusätzlicher Arbeit für bereits unter Zeitdruck stehende Teams bedeuten, und oft ist nicht klar, wer für diese Arbeit verantwortlich ist. Sie müssen den Überblick darüber behalten, welche Komponenten verwendet werden, welche Version sie haben, wo sie verwendet werden und wie sie mit anderen verwendeten Komponenten interagieren können.
Hinzu kommt die Notwendigkeit, die Lizenzierung zu vergleichen und Updates und Patches zu überwachen, sobald sie zur Verfügung stehen, einschließlich ihrer Auswirkungen auf die Funktionalität. Wenn die verwendeten Komponenten unnötige Funktionen enthalten, können sie die Komplexität Ihres Systems erhöhen, ohne einen Nutzen zu bringen.
7. Schlechte Praktiken der Entwickler
Entwickler können unbeabsichtigt Risiken erhöhen, wenn sie Codeabschnitte aus Open-Source-Software kopieren und einfügen, anstatt ganze Komponenten zu integrieren. Dadurch wird es unmöglich, diesen Code unter lizenzrechtlichen oder sicherheitstechnischen Gesichtspunkten nachzuverfolgen.
Bei der Zusammenarbeit mit anderen Teammitgliedern übertragen Entwickler Komponenten möglicherweise per E-Mail und nicht über einen Binär-Repository-Manager oder einen gemeinsamen Netzwerkspeicherort. Diese Methode kann dazu führen, dass der Code während der Übertragung manipuliert wird und Sicherheitslücken oder bösartige Funktionen eingefügt werden können.
Wie Sie sich und Ihr Unternehmen schützen können
Geeignete Tools verwenden
Der Einsatz von DevSec-Teams kann Ihnen dabei helfen, Sicherheitsaspekte früher in Ihren SDLC zu integrieren und Open-Source-Software von Anfang an sicher einzubinden. Die Sicherheitsbeauftragten können die Komponenten, die Entwickler verwenden möchten, leichter bewerten und Empfehlungen zur Risikominderung oder zur Entwicklung von Patches geben.
Automatisierungswerkzeuge können einen enormen Wert für die Verfolgung von Open-Source-Komponenten und deren Status sowie für die Bewertung von Komponenten bieten. Open-Source-Code kann vor und während der Nutzung mit Hilfe von Tools für die dynamische Anwendungssicherheitsprüfung (DAST) oder die statische Anwendungssicherheitsprüfung (SAST) gescannt werden.
Umfassende Richtlinien erstellen
In den Richtlinien sollte die Historie einer Open-Source-Komponente berücksichtigt werden, z. B. die Dichte der bekannten Probleme, die Häufigkeit der Versionsveröffentlichungen und die Zeitspanne zwischen der Identifizierung des Problems und dem Patch. Es ist wichtig zu wissen, wie stabil die an einem Projekt beteiligte Community ist und welche Art von Unterstützung sie bieten könnte oder nicht.
Richtlinien müssen vorschreiben, welche Quellen und Lizenztypen für die Verwendung zulässig sind, und sollten Entwicklern bei der Entscheidung helfen, ob sie einzelne Komponenten oder eine ganze Codebasis verwenden wollen.
Schlussfolgerung
Viele Unternehmen profitieren von der Verwendung von Open-Source-Software, und es gibt keinen Grund, warum Sie nicht auch davon profitieren sollten. Wenn Sie jedoch die Risiken kennen, die Open-Source-Software birgt, können Sie bereits im Entwicklungsprozess die Fallstricke vermeiden, die mit der gemeinsamen Nutzung von Crowd-Source-Code verbunden sind. Indem Sie die in diesem Blog beschriebenen Risiken berücksichtigen und zusätzlich zu den für die Sicherheit Ihrer Systeme erforderlichen Strategien Schutzmaßnahmen ergreifen, können Sie dazu beitragen, die sichere Nutzung von Open-Source-Software zu gewährleisten.
