Language
Country/Area
No result found
Die verborgenen Gefahren von Open-Source-Software: Ist Ihr Code bereits kompromittiert?
Im aktuellen Softwareentwicklungsumfeld ist Open Source-Software (OSS) für viele Unternehmen und Entwickler zur ersten Wahl geworden. Aber wussten Sie, dass die Verwendung von Open-Source-Software auch potenzielle Risiken birgt? Die Software Composition Analysis (SCA) ist eine Methode, mit der Entwickler die in ihren Code eingebetteten Open Source-Komponenten überprüfen können, um festzustellen, ob sie auf dem neuesten Stand sind, Sicherheitslücken aufweisen oder Lizenzanforderungen erfüllen.
Open-Source-Software erfreut sich aufgrund ihrer Flexibilität und geringeren Entwicklungskosten großer Beliebtheit, die damit verbundenen Risiken werden jedoch häufig übersehen.
Hintergrund des Risikos
Dieser Ansatz zur Entwicklung von Software aus verschiedenen Komponenten ist seit Ende der 1990er Jahre mit dem Aufkommen von Open-Source-Software immer üblicher geworden. Dieser Ansatz zerlegt die Komplexität einer großen Codebasis in kleinere Teile, um die Flexibilität zu erhöhen und den Entwicklungsprozess zu beschleunigen. Allerdings steigen die Risiken von Open-Source-Software deutlich, je mehr Komponenten verwendet werden. Diese Risiken können in fünf Hauptkategorien eingeteilt werden:
- Versionskontrolle: Risiken neuer Versionen
- Sicherheit: Schwachstellenrisiken in Komponenten – Common Vulnerabilities and Exposures (CVE)
- Lizenzierung: Risiken rechtlicher Anforderungen an geistiges Eigentum
- Entwicklung: Kompatibilitätsrisiken zwischen vorhandener Codebasis und Open-Source-Software
- Support: Risiko unvollständiger Dokumentation und veralteter Komponenten
Automatisierte Analyse und Risikomanagement werden für Organisationen, die in großem Umfang Open-Source-Komponenten verwenden, zu einer Notwendigkeit.
So funktioniert SCA
SCA-Produkte funktionieren normalerweise folgendermaßen: Zunächst untersucht die Scan-Engine den Quellcode der Software und die zugehörigen Artefakte, die zu seiner Kompilierung verwendet wurden, und identifiziert die verwendeten Open-Source-Komponenten und deren Versionen. Diese Informationen werden dann in einer Datenbank gespeichert und bilden einen Katalog der verwendeten Open Source-Komponenten. Dieser Katalog wird dann mit einer Datenbank bekannter Sicherheitslücken, Lizenzanforderungen und historischer Versionen verglichen.
Bei der Erkennung von Sicherheitslücken erfolgt dieser Vergleich beispielsweise häufig mit bekannten Sicherheitslücken, die in der National Vulnerability Database (NVD) erfasst sind. Einige Produkte verwenden für ihre Prüfungen möglicherweise zusätzliche proprietäre Schwachstellendatenbanken. Um geistiges Eigentum und die Einhaltung gesetzlicher Vorschriften zu gewährleisten, extrahieren und bewerten SCA-Produkte die von Open-Source-Komponenten verwendeten Lizenztypen. Diese Ergebnisse werden den Benutzern normalerweise in verschiedenen digitalen Formaten zur Verfügung gestellt und enthalten Risikobewertungen und Empfehlungen zu rechtlichen Anforderungen basierend auf den Anforderungen verschiedener Produkte, insbesondere Anforderungen für starke oder schwache Freigabelizenzen.
Die Ergebnisse können auch ein Service Component Manifest (SBOM) enthalten, das die in der Softwareanwendung verwendeten Open Source-Komponenten und ihre Eigenschaften detailliert beschreibt.
Verwendung von SCA
Da SCA unterschiedliche Organisationsfunktionen beeinflusst, nutzen unterschiedliche Teams diese Daten, oft abhängig von der Größe und Struktur der Organisation. IT-Abteilungen verwenden SCA, um Technologie zu implementieren und zu betreiben, und zu den wichtigsten Beteiligten zählen der Chief Information Officer (CIO), der Chief Technology Officer (CTO) und der Chief Enterprise Architect (EA). Sicherheits- und Autorisierungsdaten werden häufig vom Chief Information Security Officer (CISO) zum Management von Sicherheitsrisiken verwendet, während sich der Chief IP/Compliance Officer auf Risiken im Zusammenhang mit geistigem Eigentum konzentriert. Abhängig von den Funktionen des SCA-Produkts können diese Tools direkt in der integrierten Entwicklungsumgebung (IDE) des Entwicklers oder als notwendiger Schritt im Software-Qualitätskontrollprozess verwendet werden.
Vor- und Nachteile von SCAIn einigen Ländern, wie etwa den Vereinigten Staaten, ist die Generierung von SBOMs zwingend vorgeschrieben, um die Sicherheit der von Anbietern an Regierungsbehörden gelieferten Software zu gewährleisten.
Die Automatisierung ist der Hauptvorteil von SCA-Produkten. Wenn Entwickler Open-Source-Komponenten verwenden und integrieren, ist keine zusätzliche manuelle Arbeit erforderlich. Hierzu gehört auch die automatisierte Behandlung indirekter Verweise auf andere Open-Source-Komponenten. Aktuelle SCA-Produkte weisen jedoch auch einige wesentliche Schwächen auf, wie z. B.: Der Bereitstellungsprozess ist komplex und zeitaufwändig, es kann Monate dauern, bis die Produkte voll funktionsfähig sind; jedes Produkt verwendet seine eigene proprietäre OSS-Komponentenbibliothek, die Größe und Abdeckung dieser Bibliotheken sind begrenzt; die Raten können stark schwanken; und die Daten zu Schwachstellen beschränken sich häufig auf die Meldung nur jener Schwachstellen, die formal im NVD gemeldet wurden.
Darüber hinaus mangelt es SCA-Produkten häufig an automatisierten Anleitungen, unzureichenden Empfehlungen für Maßnahmen, die anhand der Daten in Berichten ergriffen werden sollen, und nur wenigen Hinweisen auf die rechtlichen Anforderungen für erkannte OSS-Lizenzen.
Denken Sie vor diesem Hintergrund auch darüber nach, wie Sie potenzielle Risiken von Open-Source-Software effektiver managen und Ihren Code vor Bedrohungen schützen können?
