Modul Basics

Basics

Modul 1 - Basics

Das Grundlagen-Modul sollte Bestandteil jeder Schulung sein. Es erklärt, weshalb Open Source Compliance ein relevantes Thema ist und motiviert anhand geeigneter Beispiele die Nutzung und die Konsequenzen des Einsatzes von Open Source in der betrieblichen Praxis.:

  • Grundlagen des Einsatzes von Open Source Software
  • Lizensierung und wichtige Lizenz-Typen im Überblick
  • Software-Lizensierung aus rechtlicher Sicht

Dauer: ca. 60 Minuten

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


Microsoft erweitert Githubs integrierte Vulnerability Management Fähigkeiten

Software eats the world - Microsoft eats Software?

Mit der Übernahme von Github hat Microsoft ein klares zeichen gesetzt, dass es seinen Führungsanspruch in der Gestaltung von Software nicht nur erhalten, sondern ausbauen will. Mit den nun in aller Eile geschaffenen Vulnerability-Werkzeugen in Github untermauert Microsoft seinen Anspruch als Platzhirsch in der Software-Entwicklung.

Github hat mit seiner erfolgreichen Mirror-Strategie den Anspruch als quasi-Standard-Repository für Software erfolgreich platzieren können. Neben einer stabilen und smarten Versionierungs- und Synchronisationslösung für Quellcode hat das Mirroring sämtlicher Open-Source-Projekte dazu beigetragen, das Gefühl von Größe geschickt zu vermitteln. Github wurde der Platz, an dem man Software findet.

Microsoft hat dies erkannt. Zudem haben Satya Nadella – und/oder sein Team – erkannt, welche Themen gerade in der Software-Entwicklung Relevanz entwickeln. Nachdem sich mit IoT letztlich Software in alle Arten von Gegenständen verbreitet, bekommen Schwachstellen (Vulnerabilities) und rechtliche Konformität (legal Compliance) eine erheblich höhere Bedeutung.

Mit Macht besetzt Microsoft nun dieses Thema. Durch die Übernahme von Github hosted Microsoft über Nacht einen Großteil der offenen Quellcodes dieser Welt. Die Software-Industrie hat mit CI/CD-Lösungen schon viel für ihre Qualitätssicherung getan und diese nahtlos an Github angeschlossen. Immerhin gibt es in diesem Segment noch eine handvoll alternative Lösungen.

Das leidige Thema „Schwachstellen- und Patch-Management“ ist derzeit noch etwas unsortiert, da es zum einen keiner gerne macht, zum anderen auch ein sehr zähes und unproduktives Geschäft ist. Dennoch haben Equifax und andere Fälle eindringlich aufgezeigt, was Folgen des Unterlassens sein können. Also beschäftigt sich inzwischen jeder notgedrungen damit.

Mit den in den letzten Wochen bekanntgegebenen Lösungen rund um das Multi-Language-Package-Management, die freien Vulnerability-Alerts – jetzt auch gestützt durch die Whitesource Vulnerability-Database für Enterprise Kunden — und durch die Übernahme von Dependabot – für eine Versionskontrolle á la Versioneye – stopft Microsoft diese Lücke und zementiert somit die Führungsposition von Github als Heimat allen Quellcodes.

Wer sollte sich jetzt noch mit diesen leidigen Aufgaben beschäftigen wollen, wenn er sie quasi freihaus durch ein Hosting bei Github erledigt bekommt? Vermutlich nur Verschwörungstheoretiker und Technikverliebte.

Letzten Endes bleibt es eine Vertrauenssache, wem man zutraut, die richtigen Abhängigkeiten bzw. Vulnerabilities zu identifizieren:

  • Werden hier meine tatsächlich zum Einsatz kommenden Abhängigkeiten analysiert oder dient nur das Original als Vorlage für die Alarme?
  • Können die aufgezeigten Vulnerability-Alerts tatsächlich einen Mehrwert bringen oder erzeugen sie aufgrund des hohen Lärmpegels, der mit meiner Bedrohungssituation nichts mehr zu tun hat nur ein ohrenbetäubendes Rauschen, welches meine Entwickler von der Arbeit abhält?

Die Antworten zu diesen Fragen werden die nächsten Monate liefern. Ansatz und Ambition dieses Schrittes erscheinen mir jedoch brillant! Wesentlich substanzieller als die bereits überraschende Übernahme von RedHat durch IBM.

Wenn man Einfluss und Informationsgewinn vergleicht, erschient die Cost-Impact-Ratio bei MS etwas günstiger auszufallen. Unabhängig davon verfügt Microsoft über hinreichend Capability to achieve, um das Vorhaben mittelfristig zu einem Erfolgsmodell zu drehen und den Platz als „Heimat allen Quellcodes“ zu behaupten. Was das wiederum für die Offenheit von Open Source bedeutet, mag jeder für sich selbst beurteilen.

Was bedeutet das für TrustSource?

Kurz nach dem Announcement haben mich erste Kunden gefragt, was das für uns bedeutet. Nach einiger Überlegung bin ich zu dem Schluss gekommen, dass uns diese Ergebnisse das Leben einfacher machen werden.

Zum einen ist die Maintenance so vieler Package-Manager – wir unterstützen derzeit 13 – auf Dauer ein aufwändiges Unterfangen. Open Source hin oder her, am Ende liegt die Maintenance dennoch beim Hauptsponsor.

Zum anderen erwarten wir eine verbesserte Informationslage aus den neue APIs. Derzeit ist die Information mehr als oft noch gruselig dürftig. Die Option, das Vulnerability-Assignment uns schenken zu können, ließe uns jubeln. Ich sehe das zwar noch nicht, da die Grundlage für das Vulnerability-Assignment neben einer sehr

Zudem fokussiert TrustSource auf den Compliance-Aspekt. Wir bieten eine OpenChain-konformen Prozess, samt Policy-Propagation, Trainings, einer automatisierten Legal-Analyse, die Compliance-Artefakt-Generierung, und und und. Das sind Berge von Aufgaben, die auch ein Clearly Defined nicht abbildet.

Auch erscheint mir eine Repository-basierte Analyse von Schwachstellen und Abhängigkeiten nicht unbedingt geeignet, den Lebenszyklus und die rechtliche Eignung einer Komponente im Anwendungskontext zu beurteilen. Immerhin ergibt sich die Eignung der Komponente nicht aus dem Repository, sondern dem gewählten Einsatzzweck in Verbindung mit einem kommerziellen Kontext. Dies lässt sich auf Repository-Ebene schlicht nicht abbilden.

Wir freue uns daher darauf, in den kommenden Monaten die neuen APIs zu integrieren, damit (hoffentlich) unseren Kunden eine verbesserte Informationslage zu bieten und ggf. die letzte Lücke in der Kette der Software-Herstellung zu schließen. Zudem unterstreicht es unsere Auffassung, dass wir in einem relevanten Segment aktiv sind, dass derzeit viel in Bewegung ist.

Sie wollen Ihre Open Source Compliance stärken, wissen aber nicht, wie starten?


Erweiterung des Visual-Studio-Plugins für .Net-Framework

Gestern hatten wir die Freude, das für .Net-Framework-Projekte erweiterte Visual Studio Plugin bereitzustellen. Wie vor einigen Wochen angekündigt, kann das Visual Studio Plugin nun .Net-Core und .Net-Framework-Projekte parallel scannen. Am einfachsten lässt sich das Plugin über dne Visual Studio Marketplace (kostenfrei) beziehen. Da das Plugin selbst Open Source ist, findet sich der Code auch auf github.

Ausgehend von unserer Intiative, unsere TrustSource Plattformauch den Microsoft-Entwicklern zu öffnen, haben wir nun beide Welten .Net-Framework und .Net-Core in einem Plugin vereint. Das ermöglicht es, beide Teilprojekte in einer Risk- und Compliance Lösung zu behandeln.

In einem nächsten Schritt werden die Commandline-Fähigkeiten der kombinierten Lösung ausgebaut, damit sie sich leicht in CI/CD-Lösungen integrieren lässt. Wir erwarten das Release gegen Ende des Monats.

Wir freuen uns jederzet über Informationen, Feedback und Anregungen zum Gebrauch und Einsatz unserer Plugins. Zögern Sie also nicht, uns zu kontaktieren und Ideenzu äußern.


Neues Release v1.7 bringt Notice-File-Generator

Wir freuen uns, endlich unseren Notice-File-Generator vorzustellen. Mit Hilfe des Notice-File-Generators ist es möglich, die leidige Arbeit des Zusammenstellens von Lizenzinformtionen auf wenige Clicks zu reduzieren.

Für gescannte Projekte ermittelt TrustSource die Anforderungen jeder Komponenten-/Lizenz-Kombination im jeweiligen Projektkontext und generiert daraus die erforderliche Information für den Notice-File. Sobald Änderungsnotizen oder Autoren-Angaben erfordelrich werden ergänzt TrustSource auf Basis vorhandener Informationen oder fordert diese Information ein. Durch die Shared-Component-Knowledgebase ist die ggf. erforderliche Recherche-Aufgabe nur einmal durchzuführen und für alle Plattformbenutzer verfügbar. Das reduziert die Aufwände für das Clearing erheblich!

Zudem sind im Zuge dieses Updates einige der Plugins renoviert, bzw. um die Fähigkeit des Build-Breaks sowie die Proxy-Nutzung erweitert worden. Mit Hilfe des Proxys lassen sich nun Corporate Firewalls leichter überwinden. Der Build-break erlaubt es, auf die Auswertung der Daten zu reagieren und im Falle von Violations den Build direkt anzuhalten.

Weiterhin ist es durch die neue Benutzerverwaltung möglich, sich in den Free-accounts auch mit der Github- oder LinkedIn-ID anzumelden. Zudem unterstützt das neue Identity Management die Integration von Multi-Faktor-Authentifikation (Corporate+) und das Multi-Role-Assignment. Somit word es möglich, einem Benutzer gleichzeitiig mehrere Rollen und somit Zugriff auf die damit verbundenen Services zu gewähren. Die Anbindung von LDAP und anderen Identity-Providern wird hierdurch ebenfalls erheblich vereinfacht.

Mehr Informationen zu dem Release finden sich hier


Neuer Scanner für .Net-Core Projekte

Wir freuen uns, heute ein weiteres Werkzeug in der Familie der TrustSource-Integrationen bereitzustellen: Den .Net-Core-Scanner. Die plattformunabhängige Lösung findet sich in unserem öffentlichen Github-Repo für DotNet-Integrationen.

Das Werkzeug erlaubt es, .Net-Core-Projekte zu scannen und überträgt die gefundenen Abhängigkeiten an die TrustSource-Plattform zur weiteren Analyse. Dort werden die identifizierten Komponenten bezüglich Lizenzen und Schwachstellen geprüft und im Kontext des Projektes die aus dem Einsatz resultierenden rechtlichen Verpflichtungen abgeleitet.

Das Werkzeug besteht aus zwei Teilen: Der erste Teil ist der Scanner selbst. Er löst die Abhängigkeiten auf und sammelt die zu übermittelnden Daten.  Der zweite Teil is die Konsolenanwendung, welche des ermöglicht, den Scanner über die Command-line zu steuern. Wenn im lokalen Arbeitsverzeichnis ausgeführt, reicht folgende Kommandozeile aus, um ein komplettes Projek tzu analysieren:

$ dotnet TS-NetCore-Scanner.dll -user „user@domain.com“ -key „TrustSource Key“

Die Konsolenanwendung und der Scanner sind ebenfalls in .Net-Core entwicklet und daher weitgehend plattformunabhängig. Das zugehörige Visual Staudio Plugin, welches das Tool kapselt und in die Visual Studio IDE einbindet, ist jedoch derzeit nur unter Windows verfügbar. Wer der Meinung ist, er braucht es auch auf anderen Plattformen, möchte sich gerne bei uns melden.

Damit schließen wir endlich eine wichtige Lücke in unserer Werkzeugunterstützung. Zusammen mit dem erweiterten Nuget-Crawler können die .Net-Core-Entwickler nun den gleichen Komfort eines qualitativ hochwertigen Open Source Management genießen. Aber dabei soll es nichht bleiben, wir planen mehr:

In den kommenden Wochen, werden wir in diese Lösung die Möglichkeit integrieren, auch .Net-Framework-Projekte zu scannen. Bisher gibt es dafür eine kleine Cosole-App, das soll aber genauso komfortabel werden.

Wir haffen, damit den Komfort der  TrustSource-Plattform auch für die Microsoft Entwickler besser verfügbar zu machen. Wir sind stets daran interessiert, die Lösung zu verbessern und auf die Bedürfnisse unserer Kunden anzupassen. Zögern Sie also nicht, uns mit Vorschlägen und Anregungen zu kontaktieren!


OpenChain Specification v1.2 in Deutsch verfügbar!

Dank der Arbeit einer Hand voll Freiwilliger, gibt es jetzt die gegenwärtig aktuelle OpenChain Spezifikation in der Version 1.2  auch in deutscher Sprache!

https://www.openchainproject.org/news/2018/11/07/openchain-specification-in-german

Wir danken den Mitgliedern des Übersetzungs-Teams - sind ein wenig stolz darauf, auch einen Beitrag geleistet zu haben - und wünschen viel Spaß mit dem Umsetzen! Falls es Fragen gibt, stehen wir Ihnen gerne zur Seite!

 

 


Reflexion BFOSS 2018

In guter Gesellschaft, die Sponsoren der Veranstaltung

Das war sie nun, gestern, die BFOSS 2018. Beachtlich, wie voll der Erfurter Kaisersaal geworden ist. Gegenüber dem letzten Mal ist wiederum eine erhebliche Steigerung der Teilnehmerzahl festzuhalten. Das entspricht dem gefühlten Druck, der zunehmend auf dem Thema liegt.

Ausgehend von einer Einführung in die Problematik wurden durch die Redner unterschiedliche Erfahrungen und Ansätze vorgestellt, wie sich Herstellerfirmen den Herausforderungen der OS-Governance (OSG) nähern. Mit 8 Vorträgen war das Programm voll und intensiv.

Interessant war zu sehen, dass sich die vorgestellten Ansätze zwar in Fokus, Gestaltungstiefe und jeweiliger Ausführung unterschieden, jedoch in der Ambition und dem Lösungsprozess vergleichbar sind:

  • Integration der Governance in die Tool- bzw. Build-Chain (Fail-fast)
  • Automatisierung bei der Analyse der relevanten Lizenzinformationen
  • Möglichst automatisierte Komposition der BoM
  • Bereitstellen einmal ermittelter Informationen für spätere Nutzung

Erstaunlich war für mich, wie wenig Fokus auf den Governance-Prozess an sich gelegt wurde. Das mag zum einen an den nach wie vor hohen fachlichen Anforderungen an die Werkzeuge liegen, die noch zu lösen sind. Zum anderen an den Protagonisten, die ja zumeist aus den technischen Bereichen stammen und sich daher mehr mit der technischen Lösung als mit dem Nachhalten der Ergebnisse beschäftigen.

unser Stand
Unser Stand hatte den Fokus auf Legal Compliance & Governance

Sehr erfreulich, insbesondere für uns als TrustSource, ist die übergreifende Erkenntnis, dass dieser Schritt ohne Werkzeugunterstützung nicht abbildbar ist. Aus meiner Sicht ist uns Ansatz, alles rund um die Stellen zu automatisieren, die man kennt und die rote Lampe zu zünden, wenn es manuelles Eingreifen braucht aufgrund der gegenwärtigen Situation vermutlich auch der pragmatische und zuverlässige. Ergänzend zu dieser Betrachtung, wurden darüber hinaus diese drei wesentlichen Herausforderungen immer wieder unterstrichen:

  • Einführung von Open-Source Governance ist eine Aufgabe für sich. 
Obwohl es eigentlich eine Selbstverständlichkeit sein sollte, wie das Händewaschen oder das Verständnis, niemandem etwas wegzunehmen, so ist die Notwendigkeit von IP-Schutz / OSG  doch nicht allen präsent. Diese Bewusstseinsbildung ist in einer Organisation ein harter und zäher Prozess, der viel Aufmerksamkeit erfordert.
  • Informationslage ist oft unzureichend. Software-Entwickler sind keine Rechtsanwälte und dementsprechend sind stellenweise die Grundlagen für die rechtssichere Nutzung, bzw. Bereitstellung von Komponenten gar nicht hinreichend vorhanden. Aus den Gesprächen lässt sich eine Tendenz ableiten, je hardware-näher bzw. älter die Komponenten, desto aufwänder die Aufbereitung der erforderlichen Information.
  • Unternehmensübergreifende Zusammenarbeit wird zum Thema. 
Zwar kam eine Großzahl der Vorträge aus dem Siemens/Bosch-Umfeld, jedoch lies sich generell der Wunsch nach mehr Unterstützung in der Governance-Arbeit vernehmen. Dabei wurden unternehmensübergreifende Ansätze für Repositories wie bspw. ClearlyDefined in den Fokus gerückt. Folgerichtig hat sich der AK Open Source des Bitkom dieses Thema auch als Fokus für nächstes Jahr vorgenommen.

Gerade der letzte Aspekt wurde auch in den vergangenen Monaten bereits des öfteren diskutiert. Grundsätzlich ist die Idee gut, Open Source-Mechanismen zu nutzen, um Open Source besser zu organisieren. Aber was bedeutet das?

Shared clearing - Gedankensammlung

Im Grunde genommen geht es primär um das „Clearing“ der Lizenzinformationen für das Notice-File, also die Begleitinformation, die einem Produkt, welches Open Source einsetzt, beigelegt werden muss, um die Nutzungsrechte an der eingesetzten Software sicherzustellen.

Das Konzept

Hierbei sind aufgrund der nicht standardisierten Grundlage und den stellenweise unklaren, unvollständigen oder auch fehlerhaften Lizenzbedingungen der ggf. zum Einsatz kommenden OS-Artefakte erhebliche Klimmzüge zu veranstalten, um eine rechtlich korrekte Dokumentationslage als Einsatzvoraussetzung zu schaffen.

Die Idee ist nun, dass ein Unternehmen A nach den Klimmzügen die Früchte seiner Arbeit einem crowd-sourcing-artigen Gremium überträgt und somit den anderen Unternehmen diese Arbeit abnimmt. Analog könnte das partizipierende Unternehmen aus dem bereitgestellten Pool schöpfen, um sich selbst Arbeit zu ersparen. Wenn der Pool öffentlich wäre, gäbe es hier auch keine wettbewerbsbeschränkenden Aspekte zu beachten.

Vertrauen als Basis

Dieser Ansatz erfordert jedoch nicht nur die Bereitschaft, seine Arbeitsergebnisse zu teilen, es erfordert auch Vertrauen. B muss A vertrauen, dass er seine Arbeit richtig und vollständig gemacht hat. Andernfalls müsste B die Ergebnisse von A zumindest noch einmal prüfen, was vermutlich dem eigenen Clearing nicht wesentlich nachsteht, will man es „vollständig“ prüfen.

Alternativ könnte man sich einen mehrstufigen Reifeprozess vorstellen. A stellt eine Ergebnis ein, B prüft es (weniger Aufwand als A) und bestätigt es, wenn die Prüfung erfolgreich ist. Somit könnte C tatsächlich mit recht hohem Vertrauen auf das Ergebnis zugreifen.

Anforderungen an das Clearing

Bleibt die Frage, ob ein Clearing unabhängig vom Anwendungsfall erfolgen kann. Denn das Arbeitsergebnis kann für einen spezifischen Anwendungsfall vollständig „cleared“ sein, für einen anderen noch nicht. Das ergibt sich aus den erheblich abweichenden Anforderungen, die sich aus der Kommerzialisierung, der technischen Nutzung oder der Art der Distribution ergeben.

Da es vermutlich wenige Lizenzen gibt, die eine Dokumentation untersagen, könnte man sich beim Shared-Clearing auch darauf einigen, immer die maximale Dokumentation herzustellen. Das bedeutet, immer für alle Komponenten die alle üblicherweise erforderliche Dokumentation einzufordern. Somit wäre sichergestellt, dass ein einmal eingestelltes Paket, alle Anwendungsfälle abdeckt.

Da dies wiederum erheblich erhöhte Aufwände für den Erstbereitsteller bedeuten könnte, könnte sich diese Forderung negativ auf die . Um dennoch den Ansatz nicht fallen zu lassen, wäre ggf. zu überlegen, ob nicht die Dokumentation des Anwendungsfalles, für den es erzeugt wurde, eine zu wichtige Meta-Information an dem Artefakt wäre. Damit wäre es einem Nutzer möglich, die Eignung bzw. das Risiko für den eigenen Anwendungsfall abzuschätzen.

Haftung im Shared-Clearing

Da der Einsatz hier ja in einem unternehmensübergreifenden Kontext stattfindet, stellt sich die Frage nach der Haftung. Was passiert, wenn B einen Produktrückruf aufgrund des nachweislich unvollständigen, bzw. fälschlichem Clearings durch A zu verkraften hat?
Der natürliche Reflex jedes wirtschaftlich Handelnden ist es, außerordentlichen Aufwände an möglichst an Dritte weiterzureichen. Ist A für diese Information haftbar? Das ist sicherlich etwas, das es im Rahmen des Contributor Agreements zu klären gilt. ClearlyDefined hat dies durch den Open-Source-typischen Haftungsausschluss und eine Schadenslimitierung auf 5 USD. gelöst.

Das ist sicherlich die gute Voraussetzung, um die Bereitschaft für Kontributionen zu erhöhen. Es führt jedoch wieder zur verbleibenden Prüflast seitens des Benutzers. Somit bleibt die Frage offen, welche Arbeit ihm durch die Wiederwendung erspart bleibt. Die Vorstellung den Linux-Kernel einem Clearing zu unterziehen ist sicherlich gruselig. Die Vorstellung, eine als cleared bereitgestellte Version stichhaltig zu prüfen, erscheint mir jedoch nicht weniger gruselig.

Zertifizierung als Ergänzung bzw. Alternative?

Die Idee der verteilten Zusammenarbeit ist zwar gut und passt ins Genre, tangiert jedoch ein Thema, das sich komplett außerhalb dieser Welt bewegt. Dementsprechend schwierig gestaltet sich der Anpassungsprozess.

Möglicherweise wäre eine Zertifizierungsstelle der geeignetere Ansatz? Angenommen es gäbe einen Body, der sich den Schuh der Prüfung bzgl. eines Anwendungsfalles anziehen und eine Garantie für die Vollständigkeit bzw. Korrektheit des Clearings in Form eines Zertifikates abgeben würde.
Hierdurch würden sich die Bedürfnisse beider Welten vereinen lassen. Zum einen ließen sich die Ergebnisse teilen und wiederverwenden, zum anderen wären sie hinreichend überprüf- und belastbar, um tatsächlich Einsparungen zu erzeugen.

Diskutieren Sie mit uns!

Gerne lernen wir Ihre Sicht auf diese Aspekte kennenlernen. Diskutieren Sie mit uns oder teilen Sie uns mit, was Sie für richtig halten.


Version 1.6 released

Wir freuen uns, nach der Sommerpause nun endlich die Version 1.6 von TrustSource bereitzustellen. Auch mit diesem Release erweitern wir wieder den Leistungsumfang und verbessern bzw erweitern bereits bestehende Features:

Neue Features

  • Vulnerability-alert - Es hat ein wenig gedauert, aber wir haben es geschafft! TrustSource informiert Sie nun, falls neue Schwachstellen bezüglich der von Ihnen in Ihren Projekten  verwendeten bzw. eingesetzten Komponenten bekannt werden. Das betrifft auch alte Versionen ihrer Projekte!
  • "Action required" items in inbox -Insbesondere für Compliance Manager wird unsere "Aktion erforderlich" Mailbox eine Arbeitserleichterung sein. bereits auf dem Dashboard finden sich Approval-reqeuests und  andere Aufgaben, welche Ihre Aufmerksamkeit erfordern. Mit Hilfe von Deep-Links können Sie direkt in die zugehörige Informationslage einsteigen.
  • Dependency graph - Eine Liste ist schön und gut. Wenn es jedoch darum geht die Bedeutung einer Komponente im Kontext des Einsatzes zu verstehen, ist eine graphische Abbildung oft hilfreicher. Wir haben daher eine graphische Übersicht der Abhängigkeiten hinzugefügt. Sie können den Graphen konfigurieren (Kantenlänge, Punkgröße und Gravity) und die Hierachietiefe bestimmen. Die Farben zeigen den Komponenten-Status an.

Verbesserungen

  • Überarbeitet Regeln und mehr Lizenzen - Basierend auf Erfahrungen und Austausch haben wir die Ergebnisse zu einigen Lizenzen überarbeitet. Auch konnten wir die LIzenzbasis wieder mit einigen neueren Lizenzen erweitern.
  • Verbessertes maven Plugin - Das maven plugin wurde erweitert, um auch die Check-API zu unterstützen. Somit is es auch dem einzelnen Entwickler möglich, bereits an seinem Arbeitsplatz ein Feedback über die Eignung der Komponenten zu erhalten.
  • Erweitertes Jenkins Plugin - Auch das Jenkins plugin haben wir in diesem Kontext um den Aufruf des check-APIs erweitert.

Bug-Fixes

  • Name im Einladungsformular überarbeiten - Es ist jetzt möglich, den eigenen Benutzernamen bereits im Registrierungsformular zu überarbeiten, wenn man eingeladen wurde.
  • Propagate delete aller Projektmitglieder - Das Löschen der Sichtbarkeitseinschränkung aller Module eines Projektes funktioniert wieder.

Die kommende Version v1.7 wird sich vor allem mit Sicherheit und neuen Login-Möglichkeiten (Github, etc.) sowie der Vereinfachung von Corporate SSO beschäftigen. Auch werden wir in dem Zuge das derzeitige Rollenmodell etwas flexibilisieren. AFlls Si emehr über unsere Roadmap eefahren wollen, kontaktieren Sie gerne  unser Vertriebsteam!

Falls Sie noch aus Ihrer Sicht wichtige Features vermissen, freuen wir uns mehr darüber zu erfahren.


TrustSource @ BFOSS 2018

Am 18.9. findet in Erfurt die diesjährige Bitkom FOSS-Konferenz statt. Das bereits seit einigen Jahren immer wieder trubelige Forum ist auch dieses Jahr wieder mit hochkarätigen Rednern und spannenden Vorträgen rund um das Thema Open Source Compliance vertreten. Details und Agenda finden sich auf der Seite des Bitkom.

Wir gehören zu den Veranstaltern und präsentieren TrustSource auf dem Forum. Gerne begrüßen wir Sie dort und geben Ihnen eine inddividuelle  Einführung.

Vereinbaren Sie schon jetzt einen Termin!

Termin vereinbaren

In dem Termin haben Sie die Möglichkeit, die unterschiedlichen, außerordentlichen Fähigkeiten von TrustSource live zu erleben. Unter anderem werden wir zeigen:

  • Auswertung einer Lizenz-Konstellation abhängig vom Kontext
  • Automatisches Generieren eines BoM
  • Prüfen der rechtlichen EIgnung einer Komponente im Projektkontext
  • Auffinden von Lizenzinformationen in einem Repository
  • Sicherstellen der Comlpiance anhand des Audit-Logs

Wir freuen uns auf Ihren Besuch! Nutzen Sie gerne eine der reservierten Zeiten für ein individuelles Gespräch!


Wie TrustSource Ihnen hilft, Ihre Organisation OpenChain compliant auszurichten

Wenn Sie mehr zu OpenChain erfahren wollen, lesen Sie zunächst unseren Beitrag "OpenChain in a nutshell".

Die OpenChain-Spezifikation definiert sechs Ziele. Inhaltlich stellen fünf Ziele den nachhaltigen Umgang mit Open Source Software sicher. Dabei fokussieren vier auf die hausinterne Organisation und das fünfte auf die Unterstützungsleistung von Open Source Projekten. Das sechste Ziel betrifft die Bereitschaft, nach außen zu erklären, dass man sich an den inhaltlichen Zielen messen lassen will, also die Bereitschaft zu einer Zertifizierung hat.

Dieser Beitrag stellt die Ziele kurz vor und erläutert, wie TrustSource dabei hilft, die Ziele zu erreichen

Ziel 1: Klären und Bewusstsein der Verantwortung

In einem ersten Schritt geht es darum, die Aufgaben und Verpflichtungen innerhalb der Organisation zu klären. Dies findet üblicherweise seinen Niederschlag in einer Regelung (Policy), einer Gebrauchsanweisung für den Umgang mit Open Source Software. Diese beschreibt die Rollen sowie deren Verantwortung, klärt, wie mit einzelnen Fällen umzugehen ist und beschreibt die Prozesse, welche zu befolgen sind.

TrustSource stellt eine Standard-Policy zu Verfügung. Sie kann als Ausgangslage für die Definition Ihrer eigenen Policy dienen.

OpenChain fordert weiterhin, dass nicht nur eine Policy existiert, sondern dass diese auch dem Personal bekannt ist, sie also gelebt werden kann. Hierzu ist sicherzustellen, dass ein Großteil (min 85%) der Entwicklung nachweislich von dieser Policy Kenntnis haben.

TrustSource integriert ab Version 1.7 eine Learning-Plattform mit einem Satz an Kursen, welche den Ansprüchen eines OpenChain-konformen Kurstrainings gerecht werden und Lernkontrollen ermöglichen.

Ergänzend wird gefordert, dass Prozeduren für die Erhebung und Identifikation der genutzten Open Source Komponenten sowie die Ermittlung der damit einhergehenden Rechte, Pflichten als auch Verbindlichkeiten existieren.

TrustSource stellt einen Mechanismus bereit, der den Projektkontext erhebt und die Pflichten sowie Verbindlichkeiten aus dem Einsatz vor diesem Hintergrund auflöst. Änderungen sowohl an Bestand als auch den Zielen werden automatisch dokumentiert.

Ziel 2: Zuweisen von Verantwortlichkeiten

Da die gegenwärtige Dokumentationslage im Bereich der Open Source Komponenten stark zu wünschen übrig lässt, ist mit Rückfragen und Klärungsbedarf seitens der Downstream-Nutzer zu rechnen. Das kann Rückfragen zur Nutzung bzw. den Einsatzmöglichkeiten aber auch die Bestandteile selbst betreffen. Um den Anfragen zu begegnen, bzw. diese auf einfache Art qualifiziert entgegenzunehmen, fordert die Spezifikation die Definition und Kommunikation eines benannten Kontaktes, den „FOSS-Liaison“ oder im Deutschen eher passend: „FOSS-Kontakt“.

Weiterhin fordert die Spezifikation, dass die Kommunikation nach zuvor definierten Regeln zu erfolgen hat und hinreichend dokumentiert sein sollte. Dies ist insbesondere für später ggf. anhängige Gerichtsverfahren ausgesprochen wertvoll.

Mit Hilfe von TrustSource können Sie diese Aufgabe nach außen delegieren. Sie richten eine Mail-Adresse ein und alle Incoming-Requests werden vom TrustSource HelpDesk strukturiert bzw. nach den mit Ihnen erarbeiteten Verfahren abgearbeitet.

Um den Anforderungen dabei gerecht zu werden, ist es als erheblich für den Prozess anzusehen, dass eine hinreichende rechtliche Expertise auf dem einschlägigen Gebiet vorhanden ist. Diese darf gemäß Spezifikation sowohl durch interne als auch externe Ressourcen gestellt werden.

Ziel 3: Wahrnehmen der FOSS-Aufgaben

Das dritte Ziel widmet sich der Dokumentation der erzeugten Software, bzw. der eingesetzten Artefakte. Der Prozess, um eine Stückliste (Bill of Materials, kurz BoM) zu erzeugen, sollte hinreichend qualifiziert und dokumentiert sein. Qualifiziert bedeutet, dass der Prozess sich dazu eignet, die tatsächlich eingesetzten Komponenten aufzuzeigen und sicherzustellen, dass diese Information auch im BoM auftaucht.

Das soll jedoch nicht nur einmalig zu einem Zeitpunkt passieren, sondern muss kontinuierlich für jedes Release erfolgen. Insbesondere im Zuge von Continuous Deployment entsteht hieraus eine erhebliche Verpflichtung für die Aktualität und die Archivierung der Dokumentation, bzw. der BoMs. Eine manuelle Durchführung ist im hier nicht mehr denkbar.

TrustSource kann hier optimal unterstützen. Durch die Integration mit den Entwicklungswerkzeugen lässt sich zu jedem Zeitpunkt ein BoM erzeugen. Die einzelnen Versionen lassen sich speichern und archivieren. Durch den „Freeze Release“ Mechanismus können bestimmte Versionen gezielt via API exponiert bzw. als SPDX exportiert werden. Ein aktuelles BoM ist somit stets gegeben.

Die Spezifikation macht keine Vorgaben bezüglich der Inhalte eines BoM. Jedoch hat im Kontext der Linux-Foundation die Arbeitsgruppe SPDX - Software Package Data Exchange - Vorgaben für die Lizenzdokumentation einer Anwendung erarbeitet. Diese lösen das Problem nicht abschließend, bilden jedoch eine gute Grundlage für eine technische Dokumentation.

Das Erstellen des BoM allein reicht jedoch nicht aus, um einen sicheren Umgang mit FOSS zu gewährleisten. Je nach Anwendungsfall können die Bestimmungen der inzwischen gut 396 bekannten Lizenzen unterschiedliche Verpflichtungen auslösen. So spielen der Einsatzzweck, die Art der Kommerzialisierung oder auch die Form der Distribution eine erhebliche Rolle bei der Identifikation der zu erfüllenden Verbindlichkeiten oder der ausgelösten Pflichten.

Das ist insbesondere deshalb wichtig, weil einige Lizenzen bei Nichterfüllung der Verbindlichkeiten oder Pflichten das Nutzungsrecht entziehen. In anderen Worten: Das Recht zur Nutzung der Komponente erlischt, wenn die Verpflichtungen nicht erfüllt werden. Und der Einsatz ohne Nutzungsrecht im kommerziellen Kontext, ist kein Kavaliersdelikt mehr.

OpenChain fordert daher, dass eine rechtliche Prüfung stattfindet, welche Verbindlichkeiten und Verpflichtungen in dem jeweiligen Einsatzszenario zu erfüllen sind, um eine rechtskonforme Anwendung im jeweiligen Szenario sicherzustellen.

Hier spielt TrustSource seine besondere Stärke aus. Durch Kenntnis der Bedingungen und Verpflichtungen aus mehreren hundert Lizenzen und einer strukturierten Erfassung des rechtlichen Kontextes kann die TrustSource Regel-Engine die Bedingungen für die Nutzung automatisiert fallspezifisch ableiten und somit als List of Obligations für eine Abarbeitung zur Verfügung stellen.

Ziel 4: FOSS Compliance Artefakte bereitstellen

In dem vierten Ziel geht es darum, dass die Compliance Artefakte nicht nur erzeugt, sondern auch mit der erzeugten Software ausgeliefert werden. Es ist also sicherzustellen, dass die Artefakte vollständig und Teil der Software sind.

TrustSource unterstützt dies durch die Bereitstellung eines SPDX Dokuments des entsprechenden Moduls oder Projektes. Zukünftig wird neben dem SPDX auch ein komplettes Notice-File kompiliert und bereitgestellt.

Um rechtlich konform zu agieren, ist es erforderlich, Revisionssicherheit herzustellen. Das bedeutet, alte Versionen sind zumindest solange aufzuheben, bis sichergestellt ist, dass keine alte Version mehr im Umlauf ist. Das ist erforderlich, damit sich Fragen zu einem älteren Versionsstand auch auf einer gesicherten Dokumentenlage beantworten lassen.

TrustSource kann die Information zu allen in TrustSource erzeugten Version jederzeit wieder bereitstellen.

Auf dieser Basis ist es stets möglich, zu identifizieren, welche Komponenten wo eingesetzt wurden und unter welchen Bedingungen. Einerseits macht Dokumentation angreifbar, da auch dokumentiert ist, was nicht getan wurde. Andererseits führt es aber auch zu der Sicherheit, tatsächlich alles Erforderliche unternommen zu haben, um Rechtssicherheit herzustellen. Fehler sollten bei einem solchen Vorgehen rechtzeitig aufgedeckt werden können.

Ziel 5: Verstehen der Community-Verpflichtungen

Open Source ist keine Einbahnstraße. Man sollte nicht nur nehmen, alle Nutzer von Open Source sind eigeladen, auch mitzugestalten. Dies geschieht über Mitarbeit in den open Source Projekten, sogenannten Contributions.

Hierzu werden üblicherweise für ein Engagement hausinterne Ressourcen für das Open Source Projekt abgestellt, die entweder ganz oder teilweise an dem Projekt mitarbeiten. Je nach Intensität kann dies auf gelegentlicher Basis in Form von Bugfixes oder freiwilligen Ergänzungen oder aber als definierte Abordnung zum Kern des Projektes erfolgen. Je nach Intensität eröffnet es dem beitragenden Unternehmen Einfluss auf die Gestaltung des Produktes. Es ist auch denkbar, dass das Unternehmen ein eigenes Open Source Projekt ins Leben ruft.

Ob gelegentlich oder gezielt und strukturiert, welche Form auch immer gewählt wird, die Beiträge sind klar zu regeln. Dabei geht es um rechtliche Fragen wie Trennung von Arbeitszeit und Freizeit, Ansprüchen und Rechten aus den Beteiligungen sowie dem Prozess, zur Bereitstellung von Beteiligungen.

Das fünfte Ziel nimmt sich dem Thema des Rückspielens in die Open Source Community an und verlangt, dass es eine Policy gibt, welche den Umgang bzw. die Beiträge zu Open Source Projekten regelt. Analog zur Regelung für den Einsatz von Open Source im Unternehmen, ist auch hier auch für die hinreichende Verbreitung und Bekanntheit der Regelungen zu sorgen.

Auch die Regelung zur Beteiligung an Open Source Initiativen kann mit Hilfe der gleichen Mechanismen wie die Unterstützung zu G1 genutzt werden. Auch für die Gestaltung von Beiträgen bietet TrustSource eine Sample-Policy als Grundlage.

Es kann sein, dass die Regelung eine Beteiligung an Open Source Projekten verbietet. Für diesen Fall ist nur die Bekanntheit des Verbotes zu propagieren. Aus unserer Erfahrung bietet sich ein Verbot jedoch nicht an. Sobald ernsthaft Open Source eingesetzt wird, ist mit Fehlern in der eingesetzten Software zu rechnen. Diese aufgrund eines Verbotes für Beiträge nicht beheben zu können, wäre fahrlässig.

Es ist demnach ein Governance Prozess für die Beiträge zu definieren. Im Idealfall unterscheidet sich dieser nicht wesentlich von dem für eigene Produkte, um es für alle Beteiligten einfach in der Handhabung zu machen.

TrustSource stelle eine für beide Einsatzformen einheitliche Plattform mit umfangreichen Werkzeugen für die Prozessunterstützung zur Verfügung.

Ziel 6: Bestreben, die Konformität zu zertifizieren

Das sechste Ziel fordert die Bereitschaft der Organisation die Umsetzung der Anforderungen aus den Zielen 1-5 zu bestätigen. Dies ist derzeit mit Hilfe eines Self-Audits möglich. Die Webseite der OpenChain bietet hierzu einen Fragebogen und entsprechende OpenChain-Partner unterstützen die Umsetzung.

TrustSource bietet eine geeignete Plattform, um die Prozesse sicherzustellen. Dies ist bei den einschlägigen Parteien bekannt und vereinfacht die Klärung der Prüfungen.

Zusammenfassung

Zusammenfassend lässt sich erkennen, dass der unternehmensweite Einsatz von TrustSource einen Großteil der Komplexität einer OpenChain-konformen Ausrichtung einer auch größeren Organisation erheblich reduzieren kann. Es bleibt aber auch festzuhalten, dass OpenChain die Einführung von Prozessen und die Veränderung von Abläufen erfordert. Dies ist immer ein aufwändiges Unterfangen, das Zeit und Fokus erfordert.

Wir empfehlen daher, den Scope gezielt zu wählen. Es mag durchaus sinnvoll sein, nicht gleich auf Konzernebene mit der Einführung anzufangen, sondern sich zunächst auf einen einzelnen Entity zu konzentrieren. Mit den Erfahrungen und Erfolgsgeschichten lässt sich die Einführung in einem zweiten Bereich wesentlich schneller erreichen.

Auch hier kann TrustSource in der Enterprise-Version mit der Multi-Entiy-Option helfen. Diese ermöglicht es, einzelne Einheiten/Bereiche in einem Konto zusammenzufassen und übergreifend zu administrieren, jedoch mit bereichsspezifischen Policies oder Black- und White-listen zu versehen.

Auch für Unternehmen, die bereits in eineigen Bereichen andere Scanning-Werkzeuge nutzen, kann TrustSource zur Vereinheitlichung der Ergebnisse dienen. Durch die Möglichkeit, Scan-Ergebnisse an das TrustSource-API zu übermitteln bzw. SPDX-Dokumente zu importieren, kann TrustSource das Bindeglied über mehrere, ggf. bereits existierende, bereichsspezifische Werkzeuge dienen. Somit lässt sich die Prozesskonformität und somit eine einheitliche Governance unternehmensweit sicherstellen.