Risiken der Open-Source-Lizenzierung

Für den Report „State of Open Source License Compliance“ analysierte der Anbieter Daten aus insgesamt 134 Audits, bei denen der Umfang der Nutzung von Open-Source-Lösungen in Unternehmen bis auf Codeebene erfasst wurde. Die Audit-Teams prüften eigenen Angaben zufolge die identifizierten OSS-Komponenten sowohl auf bekannte Schwachstellen als auch auf die Einhaltung der Compliance-Vorgaben. Die Ergebnisse des Open-Source-Reports:

• Pro Audit konnte Flexera durchschnittlich 367 kritische Fälle aufdecken. Die große Mehrheit (98 Prozent) war den Unternehmen vor Beginn des Audits nicht bekannt.

• Rund 16 Prozent der Treffer wurden als kritische Compliance-Risiken (Prioritätsstufe 1) eingestuft und erforderten sofortige Gegenmaßnahmen. Dazu gehören u.a. schwere Verstöße gegen Copyleft-Lizenzen, die APGL und GPL betreffen. Weitere zehn Prozent der entdeckten OSS-Fälle fielen unter Prioritätsstufe 2 (z. B. sekundäre Probleme mit kommerziellen Lizenzen). 71 Prozent der Ergebnisse entsprachen der Prioritätsstufe 3, darunter risikoarme Probleme im Zusammenhang mit permissiven Lizenzen von BSD, Apache oder MIT.

Durchschnittlich stießen die Lizenzanalysten alle 32.873 Codezeilen auf ein Compliance-Risiko, eine Schwachstelle oder Ähnliches. Diese Trefferquote erscheint zwar auf den ersten Blick relativ klein. Berücksichtigt man jedoch die tatsächliche enorme Anzahl an Code, aus denen sich Software-Produkte zusammensetzen, verändert sich das Bild. So umfasst beispielsweise die Software in modernen Autos durchschnittlich 80 bis 100 Millionen Codezeilen pro Fahrzeug.

Im Zuge der Auswertung verglichen die Analysten die Ergebnisse von forensischen Audits im Rahmen von Übernahmen und Fusionen mit weniger tiefgreifenden Baseline-Audits. Das Ergebnis: Bei M&A-Audits konnten die Analysten 30 Prozent mehr OSS-kritische Fälle der Prioritätsstufe 1 identifizieren. Bei Vorfällen der Prioritätsstufe 2 und 3 waren es sogar 224 bzw. 245 Prozent mehr. Insgesamt lieferten Forensic Audits damit doppelt so viele Ergebnisse wie eine oberflächliche Überprüfung auf Open Source.

„Mit dem Trend zu immer agileren Entwicklungsprozessen, werden Compliance- und Sicherheitsfragen beim Einsatz von Open Source oft nicht ausreichend beleuchtet. Das trifft vor allem dann zu, wenn das Unternehmen keine klaren Richtlinien zur Nutzung und Erfassung von OSS vorgibt. Viele verlassen sich auf eine oberflächliche Analyse der verwendeten Komponenten. So bleiben Details wie z.B. Snippets, die über Copy und Paste in den Code gelangen, verborgen”, erklärt Nicole Segerer, Head of IoT DACH bei Flexera. „Zudem gilt es, den gesamten Software-Zyklus im Auge zu behalten. Open-Source-Code stammt in den meisten Fällen aus unterschiedlichen Quellen wie Containern, Build Dependencies oder Binärdateien. Es geht also nicht nur darum, den eigenen, intern entwickelten Code zu kennen, sondern auch zu wissen, was über externe Partner und Drittanbieter hinzufügt wurde.“

Um Compliance-Verpflichtungen einzuhalten und Sicherheitsrisiken von Software-Schwachstellen zu minimieren, sei den Verantwortlichen daher dringend geraten, klar definierte Richtlinien und Prozesse für die Dokumentation von Open Source einzuführen. Die Implementierung eines formalen Prozesses könne unter anderem folgende Punkte umfassen:

• Interne Richtlinien zum Umgang von Open Source Software
• Stakeholder-Trainingsmaßnahmen zur Schärfung des Sicherheitsbewusstseins
• Automatisierte Software-Monitoring- und Scanning-Tools (z. B. Software Composition Analysis)
• Aufbau eines Lieferantenprogramms zur besseren Verwaltung der Anforderungen Dritter
• Gründung eines Open Source Review Board (OSRB)

Bildquelle: Thinkstock/iStock