TrustSource zeigt OpenSSF Scorcards an
Hier klicken, um das Bild zu vergrößern
In unserer Komponentendatenbank, in der wir Meta- und Clearing-Informationen zu Komponenten sammeln, haben wir die Open Source Security Foundation (OpenSSF) Scorecard ergänzt. Diese erlaubt es, den Sicherheitsstatus von Open-Source-Projekten zu erkennen. Der Score, der vom OpenSSF-Projekt der Linux Foundation im Jahr 2020 eingeführt wurde und derzeit regelmäßig für etwa 1 Million Open-Source-Projekte auf Github ausgewertet wird, ist ein aggregierter Wert, der die vom Open-Source-Projekt getroffenen Sicherheitsmaßnahmen widerspiegelt. Er kann als Anhaltspunkt dafür verwendet werden, wie sehr Sie den Sicherheitsbemühungen eines bestimmten Projekts vertrauen können, ohne es weiter zu evaluieren.
Was sagt die Scorecard aus?
Der Wert oder die Punktzahl der Scorecard ist das Ergebnis von sechzehn Prüfungen, die die Best Practise der sicheren Softwareentwicklung widerspiegeln. Sie umfassen die Bereiche Entwicklung, Tests, Wartung und Schwachstellen, aber auch Code- und Build-Management. Auf der Grundlage eines umfassenden Satzes Best Practises durchsuchen die Tests das Code-Repository nach Belegen dafür, dass die Praktiken vom Projekt aktiv angewendet werden.
Derzeit sind 18 Tests verfügbar, von denen 16 über die API zugänglich sind. Eine ausführliche Dokumentation der Tests ist hier zu finden. Jeder Test wird mit einer Punktzahl zwischen 0 und 10 bewertet, wobei 10 die bestmögliche Punktzahl darstellt. Die Testergebnis und einem Risiko gewichtet ergeben zusammen eine Gesamtpunktzahl.
In einigen Fällen, kann es sein, dass Tests aufgrund von Projekt-Setups nicht anwendbar sind. Beispielsweise könnte es sein, dass ein Projekt keine Pakete über Github bereitstellt. Dadurch wird der Test auf Pakete nicht anwendbar sein, da die aktuelle Implementierung noch keinen Mechanismus zur Überprüfung anderer Paketmanager bietet.
Wenn Sie jedoch eine Entscheidung treffen wollen, ob Sie eine bestimmte Komponente einsetzen wollen oder nicht, hilft Ihnen die Durchführung eines Scorecard-Tests – oder ein Blick auf die Komponente in unserer Datenbank – dabei, einen Eindruck zu bekommen, welchen Aufwand Sie in die Absicherung der Komponente investieren müssen. Je höher die Punktzahl, desto mehr Vertrauen können Sie in die Komponente setzen.
Was sagt die Scorecard NICHT aus?
Bitte verstehen Sie eine hohe Punktzahl aber nicht als Garantie für eine sichere Komponente! Auch eine niedrige Punktzahl deutet nicht unmittelbar auf eine schwache oder fehlerhafte Komponente hin! Es wäre schlicht falsch, anzunehmen, dass eine niedrige Punktzahl ein Hinweis auf eine anfällige Komponente ist! Derzeit sind die Tests noch nicht umfänglich und prüfen nur auf ein Set ihnen bekannter Sicherheitswerkzeuge. Auch werden nur die im Repository sichtbaren Informationen geprüft. Bleiben diese auf einem Entwickler- oder CI-System und finden nicht den Weg in das Git-Repository, tauchen sie auch nicht im Testergebnis auf!
Die Punktzahl gibt an, welche Schritte das Projekt unternimmt, um sicherzustellen, dass der von ihm bereitgestellte Code bewährten Praktiken folgt und daher mit hoher Wahrscheinlichkeit frei von Fehlern und Schwachstellen ist. Aber es ist eben keine Garantie! Wenn alles gut läuft, alle Tests 10 zurückgeben, kann es immer noch vorkommen, dass eine Schwachstelle in einer vorgelagerten Komponente auftritt, die für das Projekt selbst nicht einfach oder gar nicht zu beheben bzw. zu umgehen ist.
Verwenden Sie die Punktzahl als Indikator. Aber machen Sie die Entscheidung, ob Sie eine Komponente verwenden wollen oder nicht, primär von ihrer Funktionalität abhängig und nicht von der Punktzahl. Sie werden – vor allem in diesen frühen Tagen, in denen der Score noch nicht weit verbreitet ist – noch viele gute Projekte mit geringen Scores finden.
Was kommt als Nächstes?
Wir empfehlen, dies Scorecards als Indikator für eine Eignungsbeurteilung hinzuzuziehen, da sie einen Hinweis darauf geben, wie stark Sie sich auf Ihre vorgelagerten Komponenten verlassen können. Zudem lässt sich über eine historische Betrachtung der Veränderung des Scores eine Tendenz erkennen, die eine interesante Aussage über das Projekt und seine Einstellung zu den Best Practises erkennen lässt. Wir werden Anfang kommenden Jahres genügend Werte gesammelt haben, um diese „Tendenz“ auswerten zu können.
Da TrustSource alle KomponentenIhrer Lösung kennt, wird es nun auch möglich sein, mehr aus den einzelnen Scores in Bezug auf das Projekt zu machen. Ein einfacher Durchschnittswert wäre sinnlos. Aufgrund der Menge der Komponenten wäre ein Durchschnittswert irgendwo bei einer bedeutungslosen 5 zu erwarten. Aber wir experimentieren derzeit mit Quantilen oder Top-10- und Low-10-Durchschnitten sowie dem Verhältnis von Nicht-bewerteten Komponenten zu bewerteten Komponenten.
Außerdem werden wir einen Service anbieten, mit dem man seine eigenen Komponenten oder nicht geprüfte Open Source Repositories überprüfen kann, indem man – wie beim DeepScan einfach eine URL angibt oder auch die Scorecard auf nicht-Github-Projekte überträgt. Wenn wir erfolgreich sind, werden wir unsere Entwicklungen in OpenSSF einbringen.
Sie wollen mehr über SBOMs oder OpenSSF Coding Best Practises erfahren? Kontaktieren Sie uns!
Open Source Compliance im Kontext von CI/CD
In den letzte Jahren hat sich Continuous Integration und Deployment (CI/CD)- die ständige Integration von Änderungen, deren automatisiertes Testen und Ausbringen – als Best Practise etabliert. Die gesteigerte Qualität und die Produktivitätsverbesserungen, die sich hierdurch erzielen lassen, sind enorm und sollten daher von jedem Entwicklungsteam angestrebt werden. Gleichzeitig wächst jedoch auch die Herausforderung im Bereich Open Source eine solide Dokumentation und rechtliche Compliance herzustellen.
Durch das kontinuierlich neue Bauen von Lösungen kann sich auch kontinuierlich die Zusammensetzung der Lösung ändern. Da der Anteil an Dritt-Software (OpenSource-Komponenten) stetig zunimmt, wird mit dem neuen Bau auch die Wahrscheinlichkeit größer, dass sich die Zusammensetzung der automatisch hinzugezogenen Dritt-Software ändert. Das Upgrade der Komponente X von Version 1.5.7 auf 1.5.8 kann bereits neue Lizenzverpflichtungen auslösen.
Leider kann eine strikte Versionskontrolle alleine diese Problematik nicht auflösen, da immer wieder das Schließen von identifizierten Schwachstellen (Vulnerabilities) und anderen Fehlerbehebungen Versions-Upgrades in allen Ebenen erforderlich machen wird. Daher stellt sich die Frage, wie sich die Compliance (1) auch in diesem dynamischen Kontext sicherstellen lässt.
Branching-Konzept als Lösungsbaustein
Um diese Frage zu beantworten, ist es erforderlich, sich zunächst mit dem Prozedere des Entwicklungsteams vertraut zu machen. Leider lässt sich immer wieder feststellen, dass es keine generell einheitlich definierte Vorgehensweise gibt. Dabei ist die Branching-Strategie des Entwicklungsteams essentiell für den richtigen Ansatzpunkt einer Open Source Compliance.
Mit Git-Flow (2), Github-Flow (3) und Gitlab-Flow (4) stehen drei anerkannte, aber zunächst unterschiedlich anmutende Handlungsanweisungen zur Verfügung. Die Varianten unterscheiden sich jedoch weniger, als es auf den ersten Blick erscheint.
Im Git-Flow bleibt der Master unantastbar die Version, die sich auch im Produktivsystem findet. Hierdurch verspricht man sich, ein einfaches Rollback auf eine ältere Version, sollte das Deployment 2 PROD einer neuen Version fehlschlagen. Ausgehend von dem Develop-Branch werden einzelne Feature-Branches erzeugt und jeweils wieder auf den Develop-Branch zusammengeführt, um das parallele Entwickeln durch mehrere „Feature“-Teams an dem Develop-Objekt zuzulassen. Atlassian ergänzt in der Beschreibung zudem noch den Umgang mit Hot-Fixes und Releases.
Wesentlich einfacher erscheint der Github-Flow. Einen Teil der Vereinfachung erfährt das Modell jedoch aufgrund der Verlagerung des Masters auf die Rolle des (im Git-Flow) Develop-Branch. Das vereinfacht das Verständnis, da die meisten Werkzeuge #master als Default-Branch verwenden und somit der Entwickler im Default auf dem richtigen Branch arbeitet. Unbeantwortet bleiben im GitHub-Flow jedoch die Fragen nach dem Merge in umfangreicheren Projekten, die sich aus mehreren Modulen zusammensetzen. Damit ist man dann schnell wieder bei einem Release-Branch, wie ihn der Git-Flow kennt.
GitLab hat dies in seiner Flow-Darstellung noch einmal aufgegriffen und explizite Umgebungs-Branches eingeführt, bspw. PROD, PRE-PROD, die solche umgebungspezifischen Assemblies abbilden. Die Bedeutung solcher Varianten sollte jedoch dank dynamischer, bzw umgebungsspezifischer Container-Konfiguration sukzessive abnehmen.
Inwiefern sich das als geeignet erweist, mag nur der jeweilige Projektkontext bewerten. Aus unserer Erfahrung ist ein Failback im Kontext eines Zero-Downtime-Deployments eher weniger ein Thema, das irgendwelche Repositories betrifft. Man würde für ein Rollback sicher auch nicht auf das Soruce-Repository zurückgreifen wollen, sondern lieber die bereits gefertigten Artefakte aus einem Binary-Repository holen. Daher empfehlen wir den Verzicht auf den Git-Flow-„Master“ zugunsten eines „DEV-Masters“ im Sinne des GitHub-Flows.
Die Entscheidung, ob man noch unterschiedliche „Release“-Versionen aufhebt, ergibt sich dann aus der Deployment-Philosophie bzw. dem Geschäftsszenario. Im SaaS-Kontext ist die Dringlichkeit für Release-Branches eher geringer. Wird Software hingegen verteilt, bspw. auf Geräte, die nicht beliebig für Updates zur Verfügung stehen, ist das ein essentieller Schritt für die nachhaltige Wartung. Auf jeden Fall empfehlen wir unabhängig vom gewählten Flow eindringlich die Nutzung von Binary-Repositories, um das ewige Neubauen der Artefakte nach erfolgreichem Test und Dokumentation weitgehend zu unterbinden.
Unabhängig vom gewählten Flow emfpehlen wir stets die Nutzung von Binary-Repositories
Umgang mit Multi-Modul-Projekten
Unbeleuchtet bei all diesen Themen bleibt die Frage nach den „Multi-Modul-Projekten“. Zwar werden diese durch Modularisierungstrends wie Micro-Service-Architekturen mit der Zeit weniger werden, jedoch lässt sich nicht alles endlos teilen und nicht alle Commons lassen sich stets auflösen.
Die Frage nach der richtigen Granularität des Repository-Schnitts wird fall-, bzw. projektspezifische zu beantworten sein. Daher wird es um so wichtiger, auf Seiten der Composistion Analysis ein System zu haben, das hier vollkommene Flexibilität bietet. Wir haben TrustSource daher so konzipiert, dass es beliebige Granularitäten unterstützt. Dazu kennt es die Konstrukte „Projekt“, „Modul“ und „Komponente“.
Die Idee des Projektes ist es, ein Entwicklungsvorhaben zu klammern. Es bildet den Container, in den alles projektspezifische reinkommt: Rahmenbedingungen, allgemeine Berechtigungen, alle zugehörigen Artefakte, Infrastrukturelemente etc.
Das TrustSource-Projekt ist nur eine Klammer für eine Menge an Delivery-Artefakten.
Die Module bilden entweder einzelne Deployment- oder Build-Artefakte. Dabei kann ein Modul entweder das Ergebnis eines Builds oder eine eigenständige Drittkomponente sein. Als Build versteht sich in dem Kontext alles, was im Zuge der Eigenentwicklung gebaut wird. Das kann wiederum ein einzelnes Artefakt oder ein Multi-Komponenten Projekt (bspw. EAR) sein.
Die einzelnen Komponenten, die — auch transitiv — zum Bauen eines Moduls angezogen werden, löst der der Scanner während des Bauens auf und überträgt die Stückliste an TrustSource (s. nebenstehende Grafik). Dabei kann das /SCAN-API, welches die Information entgegennimmt, auch Informationen zu „Branch“ und „Tag“ aufnehmen. Dies hilft später, die Eingaben wiederzufinden.
Zudem unterstützt TrustSource die Verwaltung von Drittprodukten. Das können Komponenten sein, die nicht beim Bauen auftauchen, wie ein MySQL- oder JBoss-Server, eine Bild-Datei (Ressourcen) oder eine gekaufte Library. Diese lassen sich über die Mechanismen Infrastruktur Management (für Open Source-Komponenten) oder COTS-Management (für kommerzielle 3rd Party) verwalten und organisieren und einem Projekt manuell als eigenständige Module hinzufügen.
Das Modul ist also die Klammer der Informationen für ein Build-Artefakt. Es enthält den Teil der rechtlichen Informationen, die modulspezifisch sind, die Architekturposition, Zugriffsrechte etc.. Soweit Letztere nicht für das jeweilige Modul explizit geändert werden, sind sie bereits durch das übergeordnete Projekt gesetzt.
Beispiel
Nachstehendes Bild zeigt die Struktur eines Workplace-Servers. Dieser besteht aus einem Frontend- und einem Backend-Modul, die beide in einem Projekt-Repository abgelegt sind. Der Workplace-Server benötigt zudem einen Tomcat 8.5 und einen MySQL-Server als Ausführungsinfrastruktur. Diese beiden Module sind als Infrastruktur-Module hinzugefügt. Sie werden nicht gebaut, sind aber Bestandteil der Anwendung und entsprechend in die Compliance-Betrachtung einzubeziehen.
Dabei ist es egal, ob die Frontend und Backend-Module aus dem gleichen Repository kommen oder aus unterschiedlichen. Das Ergebnis in TrustSource sieht unverändert aus.
Interessant wird jetzt die Release-Strategie. Liegt die Release-Version auf Anwendungs-Ebene (äußeres Kästchen), wird es also immer nur eine Version der Anwendung geben, sind alle Module jeweils nachzuziehen, um mit der Release-Version Schritt zu halten, oder es muss eine Kombination unterschiedlicher Sub-Release zu dem Gesamt-Release geben. Zum Beispiel würde sich die Version 2.0.0 der Anwendung aus den Versionen Tomcat 8.5, MySQL 5.1 und Frontend 2.0.5 sowie Backend 1.5.16 konstituieren.
Für diesen Fall gibt es seitens des Repository nur dann eine Entsprechung, wenn ein GitLab-artiges Repository für die Produktionsumgebung gepflegt wird, in welches die unterschiedlichen Stände eingebracht werden. Es wird in diesem Kontext erforderlich – wie in allen Multi-Komponenten-on-premises-Projekten ohnehin – einen Release-Brach aufzusetzen, um das Zusammenspiel von Frontend und Backend zu testen, bevor sie ausgebracht werden.
Einbindung der Compliance in den CI/CD-Flow
Als Scan wird das Ergebnis des Scanners bezeichnet, welcher lokal oder auf dem Build-Server ausgeführt wird. Er erzeugt die Struktur inklusive Abhängigkeiten und überträgt diesen „Scan“ mit Hilfe des gleichnamigen API an TrustSource. Dort übernimmt der Scan-Processor den Scan, gleicht die gefundenen Informationen mit der internen Komponentendatenbank ab und bindet den Input an das zugehörige Modul.
Hierdurch entsteht der Kontext. Das Projekt und das Modul halten Rahmenbedingungen, welche für das Projekt bzw. Modul gelten sollen. Das betrifft die Kommerzialisierung sowie andere relevante Aspekte, wie bspw. den Schutzbedarf von IP. Diese Information zusammen mit den Komponenten und Lizenz-Informationen werden dann an den Legal-Check-Service übergeben, welcher die sich aus den Rahmenbedingungen und den Lizenzen ergebenden Verpflichtungen (Obligations) ableitet.
In der Detail-Ansicht findet der Benutzer letztendlich die Summe aller dieser Schritte, das Analyse-Ergebnis. Um eine engere Bindung zwischen dem Quellcode und der Management-Welt herzustellen, stellt TrustSource die Felder „branch“ und „tag“ in dem API /SCAN bereit. Somit lassen sich mehrere Zustände eines Moduls problemlos auseinanderhalten.
Wichtig für das Verständnis der weiteren Schritte ist es, zu verstehen, dass der SCAN die Struktur des Quellcodes wiedergibt. Dieser ist zunächst unbewertet. Erst das in der Detail-Ansicht dargestellte Analyse-Ergebnis ist eine Interpretation vor dem Hintergrund der zum Analysezeitpunkt gültigen Rahmenbedingungen! Daher gilt:
- Jeder Upload erzeugt einen neuen SCAN
- Ein SCAN wird in der Regel einem MODUL zugeordnet, wodurch er seine Rahmeninformationen erhält
- Jedes MODUL gehört zu genau einem PROJEKT – bis auf das systemeigene Sammelmodul „Unassigned“, hier findet sich alles, was nicht automatisch zugeordnet werden kann
- Jeder SCAN erzeugt mindestens ein ANALYSEERGEBNIS (automatisiert)
- Ein MODUL kann beliebig viele ANALYSEERGEBNISSE haben
- Ein SCAN kann beliebig oft an TrustSource übertragen werden, die Zuordnung zu einem MODUL lässt sich bei der Übertragung festlegen
Scans zuordnen
Aus dieser Menge an Fakten lassen sich beliebige Szenarien zusammenstellen. So kann jeder Entwickler an das Ziel-Modul seine Scans schicken und diese mit Hilfe von Branches und Tags differenzieren. Um eine direkte Zuordnung zwischen Code und Analyse-Information herzustellen, könnte man die Commit-ID als Tag anlegen.
Will ein Entwickler seine Experimente nicht in dem allgemeinen und für das gesamte Projekt ersichtlichen Modul einbringen, kann er eine eigene Projekt/Modul-Konstellation anlegen und die rechtlichen Einstellungen aus dem ursprünglichen Projekt kopieren. Somit kann er in seiner Version herumprobieren, ohne den allgemeinen Stack zu belasten.
Andererseits kann es auch sinnvoll sein, sämtliche Branches in dem Modul zu halten, um einen guten Überblick über die Veränderungen zu erhalten. Mit Hilfe des Branch-Selektors im User-Interface lässt sich jede Version direkt auswählen und einsehen.
Approvals einordnen
Doch was ist nun ein Approval? Das Approval ist ein administrativer Schritt, der es dem Projektleiter und den Entwicklern ermöglichen soll, sich von der Domänen-fremden Aufgabe der rechtlichen Begutachtung ihrer Leistung frei zu zeichnen. Hierzu bereitet TrustSource alle Unterlagen für eine Prüfung auf und stellt diese einem rechtlich gebildeten – im TrustSource-Sprech, dem Compliance Manager – zur Verfügung. Dieser muss dann nur noch die Vollständigkeit bzw. Eignung prüfen, wobei ihn TrustSource auch unterstützt, und kann dann eine Freigabe erteilen.
Die Approvals finden idealerweise nicht nach jedem Scan statt, sondern nur vor Merge-Schritten. Dabei sind der Umfang und die Häufigkeit organisationsspezifisch festzulegen. Im Regelfall erfolgt ein Merge in einem vergleichbaren Kontext wie in nachstehender Abbildung gezeigt. Dabei ist es unerheblich, ob es sich um einen Pull-request oder einen richtigen Merge handelt. Ist der zu integrierende Inhalt von einem für seinen Umfang vollständigen Notice-File versehen, kann dieser Inhalt auch in den zusammengeführten Baum übernommen werden und hält die Gesamtdokumentation somit vollständig.
Die obige Darstellung ist um die Scans und die Generierung der Notice Files erweitert. Wir empfehlen, die Notice-Files als Bestandteil einer Definition of Done aufzunehmen. TrustSource verfügt über einen Notice-File Generator. Dieser sammelt sämtliche vorhandenen Informationen und zeigt, welche Informationen noch fehlen, um den Notice-File zu vervollständigen.
Wir empfehlen, vor jedem Merge einen Notice-File zu erzeugen. So ist jeweils nur das Delta zum bisherigen Bestand zu ergänzen
Alle ergänzten Daten stehen ab dem Zeitpunkt der Ergänzung allen Projekten zur Verfügung. Somit sind allgemeine Informationen nur einmal zu erfassen. Das reduziert die Clearing-Aufwände erheblich
Die tatsächliche Gestaltung der Abläufe wird in jedem Unternehmen, vermutlich sogar in jedem Projekt, etwas anders verlaufen. Eine allgemeingültige Darstellung zu verordnen, ist daher weder sinnvoll, noch empfehlenswert. Die Wahrscheinlichkeit, dass sie mehr schadet als nutzt, ist einfach zu hoch. Auch kann es sinnvoll sein, das Vorgehen im Zeitablauf anzupassen. Wird ein Modul nur noch angepasst, ist ein weniger differenziertes Vorgehen empfehlenswert, als wenn mehrere Teams gleichzeitig an den Elementen arbeiten. Wird jedoch vor jedem Merge ein Notice-File erzeugt, ist jeweils nur as Delta zum bereits bestehenden Notice-File zu ergänzen und sowohl der Arbeitsaufwand als auch die spätere Herausforderung für die Compliance-Prüfung halten sich in Grenzen.
Literaturhinweise:
(1) Welche Herausforderungen die Compliance beantworten muss, findet sich in dem Artikel „Aktuelle Herausforderungen der Open Source Compliance“.
(2) Git-Flow: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
(3) GitHub-Flow: https://guides.github.com/introduction/flow/
(4) GitLab-Flow: https://about.gitlab.com/2014/09/29/gitlab-flow/
(5) s. https://github.com/dotnet/corefx/
TrustSource mit Vulnerability Lake (beta)
Vulnerability Lake ergänzt das TrustSource Angebot
Aufgrund vieler Anfragen haben wir uns entschlossen, unsere interne Schwachstellen-DB für unsere Kunden zu öffnen. Ab der Version 2.0 wird TrustSource seine interne „Known Vulnerability“-Datenbank für die Suche zur Verfügung stellen. Es werden mehrere Suchmöglichkeiten zur Verfügung stehen:
- TrustSource Vulnerability-Lake öffentliches Web-UI
eine öffentliche, kostenlose Suche über unsere Schwachstellendaten für die manuelle Nutzung. Zudem wird es möglich sein, sich für bis zu fünf Produkte zu registrieren, um Updates direkt in den eigenen Posteingang zu erhalten. - TrustSource Vulnerability-Lake Web-UI
eine in die TrustSource-Lösung integrierte Such-UI für unsere registrierten Benutzer - TrustSource Vulnerability-Lake API
eine API, die die Such- und Abgleichsfunktionen auch für die programmatische Nutzung bereitstellt. Eine bestimmte Anzahl von Transaktionen pro Monat wird kostenlos sein. Die API wird auch einige statistische Informationen zur besseren Interpretation der Schwachstellendaten bereitstellen.
Die öffentliche Web-Benutzeroberfläche sowie die in TrustSource integrierte Web-Benutzeroberfläche werden einen einfachen und einen Experten-Suchmodus bieten. Im einfachen Modus können Sie eine Produktinformation angeben und die Suche nach Organisation oder Version erweitern. In der professionellen Version kann dies in einem einzigen String kodiert werden, z.B. ’some-org:my-product:3.2.1′ Die Ergebnisse enthalten die typischen Informationen wie CVSS Base Score, CVE-ID, Beschreibung und weiterführende Links.
Die Daten werden alle zwei Stunden aktualisiert. Im ersten Anlauf wird die Lösung nur NVD-Daten enthalten. Später werden wir den Umfang dort erweitern, wo es sinnvoll ist. In den letzten Jahren haben wir eine steigende Verbreitung von CNAs – den Stellen, die CVEs vergeben – beobachtet. Das reduziert die Dringlichkeit, viele verschiedene Quellen zu verarbeiten. Abhängig von Ihrem Anwendungsfall kann es aber dennoch sinnvoll sein, weitere Quellen einzubeziehen. Zögern Sie daher nicht, uns zu kontaktieren, wenn Sie eine wichtige Quelle hingefügt haben möchten.
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.UITOOLSwird es für Dritte erheblich schwieriger entsprechende Namen in den Paketmanagern anzulegen, ohne dass es Aufsehen erregt.ORG.COPMANY.UNIT.UITOOLSfällt mehr auf, als die 100ste Version vonUITOOLS. - 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:
- Rechtlicher Rahmen
- 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
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:
- Wachsende Verteilung von Software-Komponenten
- Gleichzeitig steigt der Anteil von Open Source Software
- 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.
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