Best Practice für Open Source auch für Firmen, die „keine“ nutzen?

Das wundert mich, denn Experten berichten, dass in ca. 99 Prozent der Software-Audits Open-Source-Komponenten gefunden werden. Anlass solcher Prüfungen sind u. a. Verhandlungen mit Resellern wie SAP, Firmenübernahmen, strategische Finanzierungsrunden oder Compliance- und Sicherheitsüberprüfungen.

Hierbei werden in der Regel Hunderte, teilweise Tausende unterschiedliche Open-Source-Komponenten gefunden. Experten bei Analysten berichten schon länger, dass heute in der Regel schon ein Drittel des Anwendungscodes aus Open-Source- Komponenten besteht.

Das gilt auch für die SAP- Community, wo Android, Apache, Git, Java, Linux, Maven, OpenStack, Spring und Hunderte weitere kleinere oder größere Komponenten eine immer wichtigere Rolle in der IT spielen.

Daher frage ich mich, wie ich die Aussage auf meine Eingangsfrage interpretieren soll. Hat mein Gesprächspartner keinen Überblick über die hauseigene Softwareentwicklung, ist dem Unternehmen nicht bekannt oder gleichgültig, was deren Softwareentwickler tun? Wird tatsächlich keine Open Source eingesetzt und damit wichtige Innovations- und Kosteneinsparungspotenziale nicht genutzt?

Warum ist es wichtig zu wissen, ob und in welchem Umfang Open Source eingesetzt wird? Das Sprichwort „Was ich nicht weiß, macht mich nicht heiß“ schützt weder Firmen noch Management bei kritischen Problemen. Solange unbekannt ist, ob, wo und welche Open Source eingesetzt wird, kann es jedenfalls keinen wirksamen Schutz geben.

Warum ist der nötig? Open-Source-Komponenten können unklare oder gar virale Lizenztypen enthalten, die schon in einigen Fällen zu teuren Rechtsstreitigkeiten mit Open-Source-Entwicklern führten.

Inzwischen gibt es wie bei Patenten auch hier sogenannte Trolle, die gezielt Firmen angehen und damit Millionen „verdienen“. Da in mehr als der Hälfte der Audits dem betroffenen Management unbekannte Lizenztypen oder Komponenten mit kritischen GPL-Lizenzen aufgedeckt werden, ist das potenzielle Risiko sehr groß.

Bekannt sind auch Fälle, in denen Firmenübernahmen, Investitionen oder OEM-Vereinbarungen „geplatzt“ oder Firmenwerte dramatisch gesunken sind. Im Gegensatz zu Mo­bile-Apps- werden Open-Source-Nutzer auch meist nicht automatisch über neue Versionen informiert.

Das führt dazu, dass Unternehmen oft veraltete Versionen verwenden, die seit Längerem bekannte kritische Fehler und Sicherheitslücken enthalten. Entwickler müssen selbst aktiv werden und sich mühsam über Updates informieren. Dies tun auch Hacker und nutzen Informationen aus Datenbanken wie z. B. OWASP.org für gezielte Angriffe über unsichere Komponenten.

Mit Best Practices Risiken vermeiden

Wichtig ist, zuerst den Umfang der Nutzung festzustellen, auch wenn „offiziell“ keine Open Source eingesetzt wird. Firmen sollten einen Prozess definieren, in dem der Einsatz geregelt und möglichst automatisch überwacht wird, ohne dabei die Entwicklung zu behindern.

Dass dies problemlos möglich ist, beweisen Firmen wie SAP, Seeburger und Xing, die den Einsatz durch agile Prozesse und Überwachungssoftware sichern. Dies schützt vor kommerziellen Risiken sowie bei der Erfüllung gesetzlicher Anforderungen wie dem IT-Sicherheitsgesetz.

Inzwischen gibt es einige proprietäre, kommerzielle Lösungen, meist aus den USA und Israel, was aber für die Überwachung von Open- Source-Software etwas paradox wirkt.

Lösungen wie VersionEye aus Mannheim gehen hier andere Wege, sind selbst 100 Prozent Open Source (Apache-Lizenz) und können auch kostenlos für die vollautomatische Überwachung bezüglich Versionen, Lizenzen und potenzieller Sicherheitsrisiken genutzt werden.