TrustSource

Wie TrustSource vor Dependency Konfusion schützen kann

Was ist passiert?

Sicherheitsforscher haben es mit Hilfe eines Dependency-Konfusion Angriffes geschafft, sich Zugang zu diversen Hochsicherheits-Netzwerken zu verschaffen. Mit Hilfe dieses Angriffes ist es Ihnen gelungen, Informationen und Daten aus den betroffenen Netzwerken nach draußen zu schicken. Je nach Ausgestaltung des Angriffsszenarios wären jedoch auch andere Aktivitäten denkbar. Erst einmal hinter den Verteidigungslinien angekommen, lässt sich das Schadensszenario frei wählen.

Wie ist der Angriff erfolgt?

Die Sicherheitsforscher sind auf die Idee gekommen, als Sie in den veröffentlichten Open Source Werkzeugen der Firmen (Apple, Adobe, etc.) Namen privater Pakete gefunden haben.

Oft nutzen Unternehmen Open source und ergänzen gewisse Funktionalitäten oder grafische Steuerelemente mit eigenen Bibliotheken. Diese wiederum werden nur von einem Team entwickelt und als eigene Pakete bzw. Bibliotheken für andere Entwicklungsteams bereitgestellt. Das ist effizient und komfortabel, da die breite Menge der Entwicklungs-Teams sich nicht kümmern muss, das Look-and-Feel dennoch konsistent über unterschiedliche Anwendungen bzw. Services bleibt.

Spielen die Unternehmen nun Software zurück an die Community und werden die Referenzen auf solche „privaten“ Pakete nicht aus dem Quellcode entfernt, trägt die Veröffentlichung dien Namen dieser Pakete nach draußen. Das an sich ist noch nicht so gefährlich. Interessant wird dies erst, wenn die Information für eine Dependency-Attack (s. nebenan) ausgenutzt wird.

Wie können Sie sich schützen?

  • Komponenten-Namen:
    Folgen die internen Komponentennamen einem Namens-Schema, wie bspw. ORG.COPMANY.UNIT.UITOOLS wird es für Dritte erheblich schwieriger entsprechende Namen in den Paketmanagern anzulegen, ohne dass es Aufsehen erregt.ORG.COPMANY.UNIT.UITOOLS fällt mehr auf, als die 100ste Version von UITOOLS.
  • Nutzung von Paketmanager-Proxies:
    Um in dem Angriff erfolgreich zu sein, sind die lokalen Verteilmechanismen zu überlisten. Es sollte sichergestellt sein, dass für gewisse Paket-Typen, u.a. bspw. mit Hilfe der  Namenskennung ode reiner einfachen Blacklist, keine Updates von außen gezogen werden.
  • Versionsüberwachung:
    Mit Hilfe einer Versionshistorie wird es schnell möglich, festzustellen, welche Versionen im Einsatz sind. Ein Sprung von 1.2.3 zu 69.1.0 lässt sich schnell entdecken, bzw. fällt auf.

Was ist eine Dependency-Konfusion?

Moderne Package-Systeme nutzen Paketmanager, insbesondere um die stetig wachsende Zahl von Open Source Komponenten zu verwalten. Jede Build-Vorschrift enthält daher eine Liste der einzubindenden Komponenten. Unter Java ist das die POM.XML-Datei, bei Node.JS (JavaScript) ist das die PACKAGES.JSON.

In dieser Datei sind die Komponenten und die Mindestanforderungen and die Komponenten, die Versionsnummern angegeben. Da sich viele Komponenten öfter ändern, steht in den Vorschriften oft nicht nur die exakte Versionsangabe, bspw. 1.2.3 sondern ein Vermerk wie ^1.2.3, was so viel bedeutet wie: „Gib mir mindestens die 1.2.3 oder neuer.“ . Erfolgt seitens der Maintainer der Komponente eine Update auf bspw. 1.2.4 (neuer Patch) oder 1.3.0 (neues Feature) würde die eigene Lösung mit Hilfe der Formulierung beim nächsten Bauen von den Neuerungen profitieren können.

Wird nun in einem Package Manager von einem bösartigen Akteur eine neuere Version eingestellt, bspw. eine 2.1.0, so kann er relativ sicher sein, dass diese Version vom Package Management für den oben beschriebenen Kontext bereitgestellt würde. Baut das Projekt nun anständig, würde dieser schadhafte Code in ein QS-System ausgebracht und dort ausgeführt. Je nach

 

Sie wollen Schwachstellen entlang des gesamten Produkt-Lebenszyklus Ihres Produkt verlässlich überwachen?

TrustSource kann gegen solche Angriffe schützen!

TrustSource kennt die aktuellen Versionen Ihrer Module und Lösungen sowie der öffentlich verfügbaren. plötzliche Versionssprünge öffentlich verfügbarer Komponenten werden von unseren Systemen erkannt und an unser Support-Team zur Prüfung gemeldet. Kritisch einzustufende Entwicklungen werden an die Projekte zurückgemeldet.

Nutzen Sie bereits TrustSource ist Ihnen vermutlich das Konzept des „linked Modules“, des Einbindens von Releases eigener Software bekannt. Tauchen hier Versionen auf, die bisher unbekannt sind, führt auch dies zu einer Meldung an den jeweiligen Projektleiter. Somit können Sie sicher sein, entsprechende Entwicklungen schnell zu bemerken.


DeepScan - Effektive Lizenzen einfach identifizieren

TrustSource DeepScan - CLI, web-basiert oder als Teil von TrustSource

DeepScan – effektive Lizenzen einfach identifizieren: DeepScan ist ein Open-Source-Tool, das Ihnen hilft, Open Source Compliance zu erzeugen. Sie können DeepScan verwenden, um die Repositories Ihrer Lösung oder der Komponenten, die Sie anwenden, zu scannen. Es wird alle Lizenz- und – falls gewünscht – Copyright-Informationen identifizieren. Dies ist relevant, um sicherzustellen, dass Sie die Rechte und Pflichten, die mit den von Ihnen verwendeten Open-Source-Komponenten verbunden sind, hinreichend  erfüllen können.

DeepScan ist in drei Geschmacksrichtungen verfügbar:

Die CLI-Version ist zwar voll funktionsfähig, erfordert aber, dass der Benutzer die Ergebnisdatei selbst auswertet. Die CLI-Version kann ihre Ergebnisse entweder via Standardausgabe oder in einer Datei mit JSON veröffentlichen. Die webbasierte Benutzeroberfläche bietet eine komfortable Möglichkeit, die Ergebnisse zu betrachten und mit ihnen zu arbeiten. Die in TrustSource integrierte Lösung ermöglicht es Ihnen, die Befunde zu ändern und Ihre Daten mit anderen zu teilen.

Warum ist die effektive Lizenz so wichtig?

Jeder, der Software entwickelt, sollte aus zwei Gründen ein Verständnis für die Komponenten haben, die er für seine Lösung einsetzt:

  1. Rechtlicher Rahmen
  2. Sicherheit

Rechtlichen Rahmen kennen

Aus rechtlicher Sicht ist es wichtig zu verstehen, woraus Ihre Lösung besteht. Open Source bedeutet nicht, dass alles frei verfügbar ist. Freien Zugang alleine heißt nicht, dass man frei von Verpflichtungen ist. Oft sind Open-Source-Komponenten mit einer Lizenz versehen, die vom Anwender die Einhaltung bestimmter Verpflichtungen erfordert. In vielen Fällen ist das Nutzungsrecht an die Einhaltung dieser Pflichten gebunden, z.B. an die Nennung des Urhebers.

Auszug Apache 2.0

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

(a) You must give any other recipients of the Work or Derivative Works a copy of this License; and

(b) You must cause any modified files to carry prominent notices stating that You changed the files; and

(c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices ...

Theoretisch kann jede Komponente ihre eigene Lizenz haben. In der Praxis zeigt sich, dass es ca. 400 Lizenzen und unzählige Derivate gibt, die die Nutzung von Open Source regeln. Manche sind mehr, manche sind weniger restriktiv. Wenn Sie sich jedoch nicht um die Rechte und Pflichten kümmern, die mit den von Ihnen verwendeten Komponenten verbunden sind, rutschen Sie schnell aus der Rechtskonformität. Im schlimmsten Fall können die Strafverfolgungsbehörden die Geschäftsleitung von Unternehmen, die solchen Risiken nicht wirksam vorbeugen, wegen gewerbsmäßigen Betrugs anklagen.

DeepScan hilft dabei, Repositories auf Lizenzindikationen zu untersuchen und alle Ergebnisse auf komfortable Art und Weise offenzulegen. Zusammengefasst in einem Ergebnis, mit Links in die Tiefe des Repositories, die eine schnelle Nachverfolgung und Überprüfung ermöglichen.

Probieren Sie es aus!

Keine Installation oder Registrierung erforderlich…  

Wissen was drin ist, hilft die Sicherheit zu verbessern

Der zweite Grund, warum Sie die Komponenten in Ihrer Lösung besser kennen sollten, ist, um frühzeitig von Problemen zu erfahren, die mit solchen Komponenten verbunden sind. Wenn Sie die Strukturen Ihrer Lösung regelmäßig mit TrustSource scannen lassen, sind alle Versionen chronologisch verfügbar. TrustSource prüft NVD und andere Schwachstellen-Quellen auf Updates und vergleicht die eingehenden Daten mit den Informationen zu den Komponenten. Wenn Sie eine verwundbare Komponente verwenden – oder verwendet haben, erhalten Sie eine Benachrichtigung.

Dies verschafft Ihnen einen Vorteil gegenüber potentiellen Angreifern und sichert Ihre Entwicklung. Sie können Ihre Kunden, die noch verwundbare Versionen verwenden, sofort informieren und ihnen helfen, den Missbrauch der Schadstellen zu verhindern sowie mit der Arbeit an Fixes beginnen, bevor ihre Lösung attackiert wird.

Es gibt also viele Gründe, warum Sie wissen sollten, was sich in Ihrem Code befindet….

Um mehr über die verschiedenen DeepScan-Lösungen zu erfahren, die wir anbieten, sehen Sie sich dieses kurze Einführungsvideo an. Dieser Vortrag (englische Sprache) wird auf der FOSDEM 21 im Software Composition Analysis DevRoom gehalten.


ISO 5230 - Standard für Open Source Compliance verabschiedet

Am 14. Dezember 2020 hat die Internationale Standardisierungsorganisation (ISO) mit ISO 5230 den ersten Standard zur Open-Source-Compliance (OSC) veröffentlicht. Der Standard ist das Ergebnis mehrjähriger Arbeit einer Arbeitsgruppe der Linux Foundation. Experten für Open-Source-Compliance aus führenden Technologieunternehmen wie ARM, Siemens oder Toyota haben in vielen Arbeitstreffen einen einfachen, aber effizienten Ansatz geformt, um die Herausforderungen der Open-Source-Compliance zu adressieren.

Das folgende Video erklärt die Kernidee des OpenChain-Projekts. Es ist eine Aufzeichnung der 10-minütigen Einführung in das OpenChain-Projekt. Jan Thielscher hat diesen Vortrag am 6. Februar auf der diesjährigen FOSDEM gehalten. Darin stellt er die Anforderungen der Spezifikation und somit die Säulen der ISO 5230 vor (Vortrag in engl. Sprache).

ISO 5230 ist relevant für Ihr Unternehmen? Sie wollen mehr erfahren?

Zögern Sie nicht, uns für ein unverbindliches Gespräch zu kontaktieren!

OpenChain zielt darauf ab, Vertrauen entlang der Wertschöpfungskette aufzubauen. Zertifizierte Teilnehmer erfüllen Anforderungen im Umgang und der Verwendung von Open Source, die es einfach machen, sich auf die Ergebnisse zu verlassen. Wir unterstützen die Arbeit mit und an OpenChain bereits seit mehreren Jahren, und haben wesentliche Aspekte einer organisationalen Verankerung der Compliance-Idee in TrustSource eingebettet. Damit ist TrustSource bestens geeignet, sowohl die Einführung als auch die laufende Einhaltung der ISO 5230 bzw. der OpenChain-Anforderungen zu unterstützen.

Lernen Sie, mit welchen Eigenschaften TrustSource Ihre OpenChain/ISO5230 Zertifizierung unterstützen kann


Capabilities in comparison

TrustSource @ FOSDEM 2021

TrustSource @ FOSDEM 2021

wir freuen uns auf die Vorträge von @Jan Thielscher & @Grigory Markin auf der FOSDEM 2021.

Open Source Compliance Tooling – Capability Reference Architecture

Jan wird im OpenChain Dev-Room das Referenzmodell der Open Source Tooling Workgroup vorstellen, welches die fachlichen Capabilities und ihre Zusammenhänge darlegt. Das Modell ist in den letzten zwei Jahren von Mitgliedern der Arbeitsgruppe erstellt worden und soll eine Übersicht der erforderlichen Aufgaben geben, die im Kontext einer Open Source Compliance erforderlich werden. Es eignet sich auch, um die unterschiedlichen Werkzeuge abzubilden oder sich klar zu machen, welche Funktionalität sie abdecken.

Jan wird den Talk auch benutzen, um die Anbieter der Werkzeuge zu motivieren, Ihre Werkzeuge gegen das Modell zu mappen.

Capabilities in comparison

In einem zweiten Talk wird Grigory Markin im Dev-Room Software Composition das Open Source Werkzeug TrustSource DeepScan sowie den gleichnamigen, freien online Service DeepScan vorstellen. Die Lösung kann eingesetzt werden, um die erforderlichen Informationen (Copyright & Lizenzen) zu bestimmen, welche für eine rechtlich konforme Nutzung erforderlich sein können:

TrustSource DeepScan – How to effectively excavate effective licenses

In diesem 15 minütigen Talk werden Grigory und Jan kurz die Herausforderung der „effective“ Lizenzen anreißen und auf die unterschiedlichen, technischen Möglichkeiten und Herausforderungen der automatisierten Lizenzanalyse u.a. mit Hilfe der Similarity-Analyse eingehen. Abschließend werden kurz das Werkzeug, der gegenwärtige Arbeitsstand und die nächsten Schritte dargestellt.

Sie haben an dem 6./7. Februar keine Zeit, würden aber gerne mehr erfahren?


TrustSource v1.9 released!

We are happy to announce our latest release of TrustSource, version 1.9 to arrive Sept. 10th 2019!

With our v1.8 we have introduced a more detailed versioning schema allowing a closer matching between the code repos and the scan results by introducing support for branch and tag. In this release on of the major updates is the new approval, which allows to specify a combination of versions which shall be taken for an approval. But besides this, there is even more:

New Features:

  • Improved Approval Process:
    The new approval will be started as the former version. But a wizard will guide you through the steps. You will be able to give the approval a particular name, select the modules and analysis versions to apply. When you are confident with your selection and issue the approval request, TrustSource will generate all relevant documentations (Notice File, if required a SOUP file – see below – and  a new compliance report) and process the request towards the compliance manager(s).
    They will find the information in their inbox and can immediately dive into the new compliance report.
  • Compliance Report:
    The new compliance report will give a comprehensive summary of the project situation including legal and vulnerability status. Also it will the required documentation and unveil the degree of completion. Also the report will outline the changes in component status a project manager has made will be shown. Thus manual status changes will become immediately visible, comments on vulnerabilities having been muted will be available for review and more….
  • DeepScan:
    How often do you rely on the declared license? How many of us really dig deep to ensure that there is no little snippet of code containing another license? I probably better do not want to know. However, we proudly present DeepScan. This new service allows you to specify the URL of a component repository, which DeepScan then will assess for you in the background. It will search for all sort of data providing a relation to a license specification and present the findings to you. Give it a try! You might be surprised…
  • Support for Medical Device Directive Documentation:
    In 2020 the European Medical Device Directive will force developers of software related to medical devices to clearly outline all third party software and track these changes and require these to register each change (UDI-ID). We prepare to support this procedure and already offer automatically generated SOUP-lists as well ass COTS-component management. Further steps to follow, sty tuned with our newsletter.

Improvements:

  • Improved sorting and selections from lists
  • Multi-license cases will be marked as warning as long as no decision about the license to use has been made, even if both licenses would result in no obligations. Thus all required decisions will be easy to identify.
  • We were able to identify some inputs from scanners being misinterpreted, e.g. „>=“-version conditions, resulting in difficulties with the correct version matching. These cases will be properly resolved now.


TrustSource

Aktuelle Herausforderungen Open Source Compliance

Warum organisieren sich SAP, Siemens, Fujittsu, Toyota oder Orange unter dem Schirm der Linux Foundation im OpenChain-Projekt, das Standards im Umgang mit Open Source setzen will? Mit der zunehmenden Verbreitung von Software in alle Gegenstände und dem stetig steigenden Open Source Anteil, steigt auch die Notwendigkeit einer rechtlich konformen Dokumentation. Doch was verbirgt sich hinter der Anforderung? Warum ist das plötzlich so wichtig?

Zunächst zur Motivation; drei wesentliche Treiber tragen zur wachsenden Dringlichkeit bei:

  1. Wachsende Verteilung von Software-Komponenten
  2. Gleichzeitig steigt der Anteil von Open Source Software
  3. Zunehmende Automatisierung der Software-Entwicklung und Verbreitung von Continuous Integration und Delivery-Ansätzen

Aus dieser Gemengelage entsteht ein sensibles Umfeld. B erhöht zwar die Geschwindigkeit der Lieferung, verlagert aber gleichzeitig Teile der Wertschöpfung in die Hände Dritter. In Verbindung mit C kann bei jedem neuen Bau der Software eine neue Zusammensetzung entstehen, da ja alle Beteiligten – also auch die Dritten – stets weiterentwickeln.

Open Source Compliance - Risiken kennen

Dabei muss man sich vergegenwärtigen, dass solche Abhängigkeitsbäume nicht nur zwei oder drei Ebenen haben, sondern in der Regel bereits bei einem einfachen Modul mehrere hundert Komponenten und durchaus vier bis sieben Hierarchiestufen umfassen. In größeren Projekten sind’s schnell mehrere tausend Komponenten.

Ändert sich nun die Lizenz einer der Sub-Komponenten oder es wird eine Abhängigkeit mit MIT -Lizenz durch eine mit Apache-Lizenz ersetzt, entstehen für diese Subkomponente neue Veröffentlichungspflichten (Attribution = Zuschreiben des Werkes zum Autor). Und gerade die Veröffentlichungspflichten sind es, die gerne unterlassen werden.

Dabei ist auch hier Vorsicht geboten! Wie viele andere Open Source Lizenzen berechtigt auch die Apache-Lizenz den Gebrauch nur unter der Voraussetzung, dass die Lizenz und Veränderungen entsprechend deklariert werden. Wer eine Komponente unter Apache-Lizenz einsetzt, es jedoch versäumt, dies zu erwähnen, den und den Lizenztext beizulegen oder seine Anpassungen zu deklarieren, verliert das Recht, die Komponente zu nutzen!

Die rechtlich Folgen einer Missachtung können erheblich sein. Versäumt es ein Unternehmen, entsprechende Mechanismen zu schaffen, die geeignet sind, ein fehlerhaftes Inverkehrbringen zu unterbinden, so steht der verantwortliche Bereichsleiter bzw. Geschäftsführer in der Haftung. Solche Urheberrechtsverletzungen im gewerblichen Kontext sind keine Kavaliersdelikte, sondern eine Straftat, welche bei Bekanntwerden die Staatsanwaltschaft auf den Plan ruft. Als Strafe droht für die betroffenen Verantwortlichen in Deutschland ein Gefängnisaufenthalt.

Durch die zunehmende Verbreitung von Software in alle Arten von Geräten (A) verschärft sich das Risiko, da die Möglichkeit, Zugang zu der Software zu erhalten und sie in ihre Bestandteile zu zerlegen, ebenfalls steigen. Es ist vermutlich nur eine Frage der Zeit, bis windige Gestalten hieraus ein Geschäftsmodell ableiten. Auch für enttäuschte Mitarbeiter bietet dieser Bereich ein geeignetes Feld für einen Rachefeldzug.

Auszug Apache 2.0 Lizenz:

(…)
4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
(a) You must give any other recipients of the Work or Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
(…)

Im Kontext von Serienprodukten liegt die enorme Bedrohung dabei nicht unbedingt nur in der strafrechtlichen Konsequenz für den betroffenen Manager, auch ein Rückruf der in Umlauf gebrachten Produkte könnte eine zwingende Folge sein, wenn sich das Problem nicht anderweitig heilen lässt, beispielsweise durch Nachreichen einer Dokumentation an alle bisherigen Käufer oder vergleichbarer Ansätze.

Wie einen dies treffen kann, hat Dr. Ibrahim Haddad (Samsung Open Source) in seiner Präsentation „Guide to Open Source Compliance“ (2) dargestellt. Er beschreibt einen Fall von Cisco. Cisco kaufte 2003 die Firma Linksys für gut 500 Mil USD. Linksys hatte in seinem WRT54G Broadband-Router ein Chipset von Broadcom verbaut. Dieses wiederum nutzte angepassten Linux-Code, den die Firma CyberTAN Broadcom zur Verfügung gestellt hatte. Linux ist GPL-lizensiert, damit sind Anpassungen und damit verbundener Code veröffentlichungspflichtig. Die FSF hat geklagt und am Ende hatte Cisco nicht nur viel schlechte Presse, sondern auch einen Schaden von gut 50 Mil USD und musste seinen Code und damit eine Menge teuer erworbenes Intellectual Property ebenfalls veröffentlichen.

Bleibt also die Frage, wie sich diese Risiken eliminieren lassen?

OS Compliance - Pflichten erfüllen

Es gibt bereits eine Vielzahl von Herangehensweisen und Prozessen. Den aus unserer Sicht vollständigsten Ansatz beschreibt die OpenChain Spezifikation(3). OpenChain (4) ist ein Projekt der Linux-Foundation. Es hat sich zum Ziel gesetzt, Sicherheit und Vertrauen bezüglich des Einsatzes von OpenSource entlang der Software-Wertschöpfungskette zu gestalten. Die Spezifikation liegt derweil in der Version 2 vor und ist auf dem Weg, zu einem ISO-Standard erhoben zu werden.

Sie beschreibt ein Set von sechs Zielen und den Anforderungen, um diese Ziele zu erfüllen. Unternehmen, die diese Ziele erfüllen, können als OpenChain-konform angesehen werden und haben somit ein entsprechendes Compliance-System in ihrer Organisation verankert. Nachstehendes Bild gibt einen Überblick der Anforderungen.

Neben der Anforderung an die organisatorische und prozessuale Gestaltung lässt OpenChain jedoch die Art der zu erzeugen Dokumentationsartefakte offen. Um diese Lücke zu schließen, sind im Folgenden die Elemente vorgestellt, mit deren Bereitstellung sich die oben beschriebenen Risiken vermeiden lassen.

Zum einen ist es erforderlich, Transparenz über den Inhalt zu schaffen, also eine Art Stückliste mitzuliefern. Diese Stücklisten, oder auch als Bill of Materials bezeichnet, haben bereits einen Standard für die Beschreibung erhalten, im ebenfalls unter der Linux Foundation gestaltetem SPDX-Projekt (5). Dort wird ein maschinenlesbares Format beschrieben, welches die Inhalte einer Komponente beschreibt. Es erlaubt eine entsprechend feingranulare Darstellung der Inhalte und eignet sich für die Repräsentation einer Stückliste.

Für jede OSS-Komponente in dieser Stückliste sind dann zusammenzustellen:

  • Informationen, die die Software konkret identifizieren (Version)
  • Die Lizenz, unter der die Komponente eingesetzt wird (s. u. Mehrfachlizenz)
  • Änderungen, die an der Komponenten vorgenommen wurden, wenn die Lizenz dies erfordert
  • In einigen Fällen erfordern Lizenzen auch die Nennung der Autoren (Copyright-holder)

Wir unterstützen Unternehmen dabei, die Prozesse und Verantwortlichkeiten zu identifizieren und spezifikationskonform aufzusetzen. TrustSource integriert dem konformen Prozess optimal in die Arbeit des Entwicklers und erleichert somit das Erfüllen der OpenChain Anforderungen.

SPRECHEN SIE UNS AN

Im Kontext einer Distribution ist darüber hinaus in einigen Fällen der Lizenztext hinzuzufügen. Weiterhin gibt es einige Lizenzen, die auch im Kontext einer binären Distribution die Bereitstellung des Quelltextes erfordern. In diesem Fall wäre ein Angebot zur Übermittlung der Quellen beizulegen, die sogenannte „Written offer“.

Diese Informationen lassen sich nicht immer einfach ermitteln. Es ist aber möglich, einige davon aus den unterschiedlichen Quellen und Repositories der jeweiligen Projekte zusammenzutragen. TrustSource kenn beispielsweise die Abhängigkeiten von gut 20 Mil Open Source Komponenten in allen Versionen, was wiederum gut 500 Mil Abhängigkeiten darstellt. Hier ist schon eine Menge Arbeit getan, jedoch wächst der Pool an Open Source Software täglich. Daher stehen diverse Prüf- und Verifikationsmechanismen zur Verfügung.

Um diese Aufgaben zu erleichtern, hat TrustSource den Notice-File-Generator entwickelt. TrustSource setzt im Paket-Manager der jeweiligen Entwicklungsumgebung an und erzeugt das Bill of Materials der tatsächlich eingesetzten Software-Komponenten. Dieses wird anschließend vom Legal Check Service, der die Lizenzen kennt, im Kontext des Projektes auf Veröffentlichungspflichten sowie andere Verpflichtungen geprüft. Im Ergebnis entsteht eine Ampel, die es erlaubt, automatisiert den Build zu stoppen, wenn Verletzungen auftreten.

Weiterhin verfügt TrustSource über einen Notice-File-Generator. Dieser erzeugt basierend auf dem Bill of Materials und den Erkenntnissen aus dem Legal Check das Grundgerüst für das Notice File. Diese Vorlage wird anschließend mit den Informationen zu den Komponenten aus der geteilten Datenbank gefüllt. Somit bleibt dem Bearbeiter nur noch die bestehenden Lücken zu schließen. Seine Eingaben werden wiederum der Komponenten DB hinzugefügt und stehen dem nächsten zur Verfügung.Einfacher lässt sich eine rechtlich konforme Dokumentation derzeit nicht herstellen.

Open Source Compliance - Sonderfälle klären

Nun ist die Welt leider nicht rund und es gibt noch tieferliegende Herausforderungen im Bereich der Compliance.

Multi-License

So gibt es beispielsweise Komponenten, die nicht nur unter einer Lizenz, sondern unter mehreren veröffentlicht werden. In einem solchen Fall muss sich der Entwickler festlegen, unter welcher Lizenz er die Komponente einsetzen will. Diese Entscheidung sollte sich im Notice-File entsprechend wiederfinden, da ja hier die entsprechenden Anforderungen zu erfüllen sind.

TrustSource weist auf diesen Multi-License-Fall hin, fordert eine Entscheidung ein und verwendet anschließend die gewählte Lizenz, bis sie wieder geändert wird. Die Entscheidung wird dokumentiert und kann begründet werden.

Deklariert vs effektiv

Ein anderer, sehr kritischer Fall, sind fälschlich deklarierte Lizenzen. So kann es beispielsweise vorkommen, dass ein Paket als Apache 2.0 Lizenz deklariert ist, jedoch weitere Drittbausteine einsetzt, die einer anderen Lizenz unterliegen. Das ist eher die Ausnahme als die Regel, aber es birgt ein erhebliches Risiko. Beispielsweise die Komponente Mapfish kommt als BSD lizensiert daher. Dennoch setzt sie unter anderem das Sencha-Framework ein, welches eine kommerzielle Lizenz erfordert.

Für die rechtliche Wirkung ist die effektive Lizenzierung wichtig, nicht die deklarierte. Die effektive Lizenzierung entsteht durch die Bemerkungen im Quellcode. Der Hinweis „AGPL-2.0“ in einer einzelnen Quelldatei kann ausreichen, eine effektive Lizenzierung dieser Datei unter AGPL zu erzeugen. Natürlich gilt, „Wo kein Kläger, da kein Richter“. Wer jedoch ein Produkt in den Markt bringt, sollte sich von diesen Gedanken nicht leiten lassen.

Um diese Risiken auszuschalten, hat TrustSource den Service DeepScan entwickelt. Mit Hilfe von DeepScan kann ein Repository bzw. eine Reihe von Repositories noch einmal überprüft werden. Dies erlaubt es, eine gesamte Dependency-Hierarchie vollständig auf Hinweise nach Lizenzen zu untersuchen. Die Ergebnisse werden übersichtlich in einer Zusammenfassung angezeigt und kritische Elemente lassen sich direkt aus dieser Übersicht ansteuern.

Keine Lizenz

Eine weitere Sondersituation ist der „No license“-Fall. Tatsächlich gibt es einige Komponenten, die über gar keine Lizenzdeklaration verfügen. Einige Autoren haben ihre Ergebnisse „public domain gestellt“. Es mag hier zum Ausdruck kommen, dass sie ganz philantrophisch die Komponente allen zugänglich machen wollen. Das ist nett und auch sehr löblich. Leider ist es aus rechtlicher Perspektive eine Katastrophe, da „public domain“ vielleicht im englischsprachigen Raum eine Bedeutung haben mag, jedoch weder im angelsächsischen Recht noch im deutschen gibt es hierzu eine Rechtsfestlegung. Auch ist „public domain“ keine bekannte, gültige Lizenz.

Somit liegen trotz der Deklaration alle Rechte beim Urheber. Es ist rechtstechnisch gesehen, verboten, diese Komponenten zu nutzen, zu verändern zu verteilen oder gar zu verkaufen! Die „No license“ gehört auf jede Black-Liste ganz nach oben.

Um solche Fälle aufzulösen, bietet es sich an, den Autoren zu kontaktieren. Man kann ihm freundlich die Thematik erklären und ihn bitten, eine Lizenz, gegebenenfalls sogar einen Vorschlag anbei, hinzuzufügen. Erfolgt dies jedoch nicht, birgt die Verwendung ein hohes Risiko. Denn auch wenn jemand heute die Annahme vertritt, er möchte großzügig sein, ist ein Leben gerne mal wechselhaft und die Meinung kann sich ändern. Wer sein IP nicht gefährden will, sollte Abstand von solchen Komponenten halten.

TrustSource weist Komponenten ohne Lizenzen stets als Verletzung aus. Auch hier lässt sich der Hinweis durch den Benutzer übersteuern, wenn er das Risiko eingehen möchte, ein Compliance Manager erhält jedoch stets den Hinweis, dass solche Komponenten in dem zu begutachtenden Konstrukt verbaut sind.

Fazit

Zusammenfassen lässt sich erkennen, dass Open Source Compliance zwar eine wachsende Herausforderung darstellt, es jedoch auch hinreichend Initiativen und Lösungen gibt, den daraus entstehenden Aufwand erheblich zu reduzieren.

Die Gestaltung einer Open Source Policy – also der Definition von Verhaltensregeln, Vorgehen und Verantwortlichkeiten bei er Nutzung von Open Source – kann ein erster Schritt sein. Unter https://www.trustsource.io/resources finden sich Vorlagen und Hinweise, wie sich eine Open Source Governance erfolgreich aufsetzen lässt. Die SaaS-Lösung TrustSource stellt eine erhebliche Unterstützung für die Einführung und Aufrechterhaltung einer effektiven Open Source Governance dar.

Literaturhinweise:

(1) Welche Herausforderungen die Compliance beantworten muss, findet sich in dem Artikel „Aktuelle Herausforderungen der Open Source Compliance“.
(2) Dr. Ibrahim Haddad (Samsung), „Guide to Open Source Compliance“, https://de.slideshare.net/SamsungOSG/guide-to-open-source-compliance , Slide 62
(3) OpenChain Spezifikation v2.0 (deutsche Übersetzung) https://github.com/OpenChain-Project/Specification-Translations/tree/master/de/2.0.
(4) OpenChain Projekt s. https://www.openchainproject.org ACHTUNG! Nicht zu verwechseln mit dem gleichnamigen OpenSource Blockchain-Projekt!
(5) SPDX-Projekt, s. https://spdx.org


Aktuelle Entwicklungen

Modul 8 - Aktuelle Entwicklungen

Open Source ist in Bewegung – Tools, rechtliche Anforderungen und Geschäftsmodelle ändern sich ständig. Dieses Modul gibt einen Überblick über die aktuellen Entwicklungen der letzten 12 Monate

  • Aktuelle Rechtsprechung und neue rechtliche Anforderungen
  • Neue und aktualisierte Lizenzbedingungen
  • Überblick über neue Tools, Features und Funktionen

Dauer: ca. 60 Minuten

Zielgruppe: Entwickler, Projekt Manager, Product Owner, Compliance Manager, Architekten


Tools

Modul 7 - Tools

Ob Github, Jenkins oder Tern, alle verwalten Schwachstellen, geben Lizenzinformationen und unterstützen bei der Software-Qualität. Was gibt es wo und wie verlässlich ist es? Welche Werkzeuge sind am Markt, welche setzen sich durch? Lernen Sie, was Sie in Ihren Unternehmen einsetzen sollten:

  • Überblick über die Landschaft der Open Source-Tools und ihre Einsatzbereiche
  • Scanner vs. Compliance Management Lösungen
  • Praxisicheck: Funktionen und Features

Dauer: ca. 60 Minuten

Zielgruppe: Product Owner, Compliance Manager, Architekten


Zertifizierung und Auditierung

Modul 6 - Zertifizierung und Auditierung

Die Anforderungen an Open Source Governance sind komplex. Eine Zertifizierung nach einem anerkannten Standard wie OpenChain hilft bei der Umsetzung von „Best-Practice“ Ansätzen und schafft Vertrauen. Intern und externe Auditierungen (z.B. bei M&A Transaktionen) werden durch den Rückgriff auf etablierte Standards erleichtert. Das Modul führt in die Zertifizierung nach Open Chain ein und erklärt, welche Punkte bei der Auditierung von Open Source Governance Systemen zu beachten sind:

  • OpenChain Grundlagen und Zertfizierung
  • Prozess vs. Produkt-Zertifzierung
  • Checklisten für Auditoren

Dauer: ca. 60 Minuten

Zielgruppe: Auditoren, Compliance Manager, Einkäufer


Procurement

Modul 5 - Procurement

Eingekaufte Software enthält fast immer Open Source Software. Zusicherungen der Anbieter sind eine Sache. Doch wo gelten sie und was ist vom Paperwork im Ernstfall zu erwarten? Welche Dokumente sollten Sie einfordern? Mehr dazu erfahren Sie in diesem Modul:

  • Open Source im Kontext der Beschaffung von 3rd-Party Software
  • Vertragsgestaltung bei der Auftragsvergabe (3rd Party / Gewerk)
  • Doumentations- und Nachweispflichten und Spot-Checks

Dauer: ca. 90 Minuten

Zielgruppe: Projekt Manager, Product Owner, Compliance Manager, Einkäufer