Openchain - Umfrage zu Open Source
Openchain - Umfrage zur Opensource Nutzung
Die Openchain Workgroup der Linux Foundation, die in den letzten Jahren vor allem den Standard ISO 5230 – Open Source Compliance geprägt hat, hat ein Umfrage über den Einsatz und Umgang von Open Source in Unternehmen erarbeitet. Als internationale Erhebung soll sie helfen die Arbeit der Organisation zu fokussieren und den teilnehmenden Unternehmen eine Möglichkeit geben, sich selbst in Bezug auf Open Source zu reflektieren. Die Ergebnisse der Umfrage werden unter Creative Commons zero (CC-0) lizenzesiert und lassen sich somit frei verwenden.
Als Unterstützer der Openchain Initiative rufen wir unsere Kunden und Partner auf, die Umfrage zu unterstützen und damit den Pool an Informationen anzureichern. Die Umfrage erfordert ca. 10 Minuten Zeit und kann unter diesem Link erreicht werden.
Freies Open Source Compliance Basics Training bereitgestellt
Seit Jahren tauchen im Kontext Open Source immer wieder die gleichen Fragen auf:
- Darf ich open source in geschäftlich genutzten Anwendungen verwenden?
- Welche Folgen hat die Verwendung von open source?
- Ist die GPL eine „giftige“ Lizenz?
- Was bedeuten für uns in Europa die amerikanischen Lizenzen?
Die Irritation trifft vor allem Entwickler, die sich in vorderster Front mit der Nutzung bzw. dem Einsatz von Open Source konfrontiert sehen. Nun sind Informatiker selten auch gleichzeitig Juristen und auch wenn sich Jura und Informatik in vielen Aspekten ähneln, so ist es doch nicht trivial, eine Lizenz ohne juristische Vorkenntnisse zu interpretieren.
Um diese Lücke überwinden zu helfen, haben wir ein grundlegendes Open Source Compliance Basics – Training zur Verfügung gestellt. Das Training führt in die Thematik ein, schildert kurz die Hintergründe und gibt Einblick in die wesentlich Gestaltungsaspekte von Lizenzen. In dem frei verfügbaren, self-paced Online-Trainingskurs wurden mehr als 4 Stunden Videomaterial, Präsentationen und Quizzes verarbeitet.
Der Teilnehmer erhält in dem Kurs einen Überblick über:
- Die Motivation und Hintergründe von Open Source Compliance,
- Die Herausforderungen, die Open Source Compliance zu mehr als dem einfachen Erstellen einer Liste machen,
- Lösungskonzepte, die helfen, eine Standard-konforme Open Source Compliance in einem Unternehmen zu verankern,
Die in englischer Sprache gehaltenen Vorträge sind in kleine, kurze Häppchen eingeteilt, sodass sie sich auch zwischendurch gut verarbeiten lassen.
Den direkten Zugang finden Sie hier auf der Seite unter Trainings.
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 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
Open Source Governance
Modul 3 - Open Source Governance
Dieses Modul adressiert die Grundlagen der Open Source Governance. Neben den Rollen und ihren Verantwortlichkeiten werden typische Prozesse und Organisationsmuster für unterschiedliche Organisationsgrößen eingeführt:
- Bausteine einer Open Source Governance
- Verteilung von Rollen und Verantwortlichkeiten
- Inhalte einer Open Source Policy
Dauer: ca. 90 Minuten
Zielgruppe: Entwickler, Projekt Manager, Product Owner, Compliance Manager, Architekten, Auditoren