Zum Inhalt springen

Entwickeln Sie intelligenter, nicht schwerer.

Verwenden Sie immer die höchste Qualität und die sichereste Open Source-Komponente für den Job.

Dies ist eine großartige Möglichkeit, um manuelle Nacharbeiten zu vermeiden.


Die Nexus-Plattform

SON_Product_Overview_Refresh_Product_Map_Desktop-transparent.png
Quelle: https://de.sonatype.com/products-overview

Für einzelne Entwickler ...


  • Entwickeln mit besseren Open-Source-Bibliotheken
  • Sofortige Erkennung und Beseitigung von Schwachstellen
  • Lassen Sie intelligente Roboter Ihre Routinearbeit erledigen (Dependency Management)

Nachweisliche Erfolge:

Zufriedenere Entwickler sind innovativer, verschwenden weniger Zeit auf die Untersuchung von Fehlalarmen und sind um 38 % produktiver.

Für Teams im Bereich Anwendungssicherheit ...


  • Shift security left.
  • Automatische Erkennung von Open-Source-Risiken.
  • Rasche Behebung bekannter Schwachstellen – frühzeitig, überall und im richtigen Maßstab.

Nachweislicher Erfolg:

CISOs minimieren Risiken, setzen Open-Source-Richtlinien automatisch um und erhöhen die Anwendungssicherheit um 63 %.

Für DevSecOps ...


  • Schnellere Bereitstellung, geringeres Risiko.
  • Umfassende Abstimmung von Dev-, Sec- und Ops-Teams.
  • Automatisierte Governance für jede Phase Ihrer CI/CD-Pipeline.

Nachweisbare Erfolge:

Führende IT-Unternehmen entwickeln kontinuierlich innovative Lösungen mit Open-Source-Komponenten der Spitzenklasse und verbessern die Software-Qualität um 48 %.


OSS Compliance

Open-Source-Komponenten werden heute mit einemAnteil von 80 bis 90 Prozent in Software-Lösungen verbaut. Aus rechtlicher Sicht darf Open-Source-Software im Rahmen ihrer Lizenzbedingungen von jedermann kostenlos verwendet, bearbeitet und verbreitet werden. Entwickler haben ein Faible für diese frei verfügbaren Bauteile, die eine Vielzahl von Problemen lösen. Doch es gibt viele, mit den freien Open-Source-Komponenten verbundenen lizenzrechtlichen Risiken und manch ein Unternehmen musste bereits schmerzvoll erfahren, dass „frei“ nicht „ohne Pflichten“ oder gar „ohne Haftung“ bedeutet. Werden Lizenzvereinbarungen verletzt, so hat dies häufig Abmahnungen mit der Aufforderung zur Abgabe eines Unterlassungsversprechens zur Folge. Im schlimmsten Fall drohen bei gerichtlicher Durchsetzung Ansprüche auf Vertriebsstopp oder roduktrückrufe und Schadensersatzforderungen wegen  Urheberrechtsund/oder Vertragsverletzung ur Folge. Sogenannte „Lizenztrolle“, also auf Abmahnungen spezialisierte Juristen, brauchen Sie edoch nicht zu fürchten, wenn Sie wissen, worum es geht und was zu tun ist:

PUNKT 1

OSS-Lizenzen sind lizenzrechtlich bindend

Open-Source-Software darf prinzipiell von jedermann ohne Entrichtung einer Lizenzgebühr benutzt, bearbeitet und verbreitet werden. Dabei ist zu beachten, dass eine OSS-Lizenz immer auch ein Lizenzvertrag zwischen Entwickler und dem Nutzer ist und dass jede Lizenzvereinbarung einer individuellen Auslegung bedarf. Hinweise zur Interpretation sowie auf etwaige Sonderregelungen des Entwicklers sind beispielsweise auf der Webseite des Entwicklers oder Projekts (FAQs) oder bei „License Stewards“ wie der Open Source Initiative (OSI) sowie der Free Software Foundation (FSF) zu finden.

PUNKT 2

Copyleft beachten

Das „Copyleft“ ist eine Klausel in urheberrechtlichen Nutzungslizenzen, die den Lizenznehmer verpflichtet, jegliche Bearbeitung des Werks unter die Lizenz des ursprünglichen Werks zu stellen. Das bedeutet, dass die durch OSS-Lizenz gewährten Rechte weiterzugeben sind, wenn der so lizenzierte Code für ein neues Produkt verwendet wird. Damit soll eine kommerzielle Verwertung des Werks, beispielsweise einer Software-Komponente, verhindert werden. Ein Entwickler, also in diesem Fall der Rechtsinhaber, kann bei Zuwiderhandlung ggf. Ansprüche wegen Urheberrechtsverletzungen gegenüber allen Beteiligten der Lieferkette geltend machen.

PUNKT 3

GPL und die damit verbundenen Pflichten

Die General Public License (GPL) ist die am weitesten verbreitete freie Lizenz und Paradebeispiel für eine Copyleft-Lizenz. Die wesentlichen Pflichten des Lizenznehmers bei Weitergabe bestehen in der Mitlieferung des Quelltextes bei der physischen Weitergabe des Codes, der Zugänglichmachung des aktuellen Quellcodes, das Verbot von Lizenzgebühren, der Hinweis auf das Urheberrecht sowie die Weitergabe veränderter Versionen nur mit ursprünglichen Lizenzbedingungen (Copyleft-Effekt).

 


Quelle: https://www.sonatype.com/hubfs/Whitepaper-LicensingCompliance-DACH-2020/Whitepaper-LicensingCompliance-DACH-2020-PDF.pdf/

PUNKT 4

AGPL & LGPL — Lizenzvarianten auf Basis der GPL

Die GPL dient als Vorbild für viele andere Open Soure Lizenzen und bildet die Basis für zwei Lizenzvarianten, AGPL (Affero General Public License) und LGPL (Lesser General Public License). Eine als „ASP-Schlupfloch“ bezeichnete Lücke in der GPL besteht darin, Software nicht physisch, sondern virtuell, beispielsweise als Dienst oder online als SAAS, weiterzugeben. Dadurch besteht die Möglichkeit GPL-Software im Hosting bzw. als Application Service Provider (ASP) anzubieten. Unternehmen hätten somit ein Monopol auf Erweiterungen und Verbesserungen der Software. Die AGPL schließt dieses Schlupfloch und bietet dem Nutzer der Software eine Download-Möglichkeit für den Quelltext, unabhängig davon, ob die Verfügbarmachung physisch oder virtuell erfolgt. Analog wurde speziell für Software-Bibliotheken (z. B. GNU C Library) die LGPL entwickelt, die ebenfalls als GPL basiert. Diese ermöglicht die Verlinkung eigener (propietärer) Software mit LGPL-Software jedoch ohne den starken „Copyleft-Effekt“ der GPL. Dennoch greifen auch hier einer Vielzahl von Pflichten!

 

PUNKT 5

Vertragsgestaltung innerhalb der Lieferkette

Vor der Vertragsgestaltung mit Zulieferern (Einlizenzierung) muss geklärt sein, welche Open Source Produkte überhaupt in die Lieferkette aufgenommen werden sollen. Gegebenenfalls ist hier bereits eine Differenzierung nach Lizenzen sinnvoll. Entsprechende Vorgaben an den Zulieferer gestellt werden. Dieser muss seinen Offenlegungs- und Dokumentationspflichten nachkommen und beschreiben, welche Komponenten genau in seinen Produkten enthalten sind und welche Pflichten aus den Lizenzen zu beachten sind. Ein abschließender Compliance Check sollte dennoch obligatorisch sein! Entsprechend gilt für die Vertragsgestaltung mit Kunden (Auslizensierung): Die transparente Einbeziehung der OSS-Lizenzen, die Offenlegung welche Lizenz für welche Komponente gilt sowie die Berücksichtigung integrierter OSS im Hinblick auf mögliche Ansprüche des Kunden, sind essentielle Bestandteile einer sorgfältigen Vertragsgestaltung, die wesentlich zur Minderung von Haftungsrisiken beiträgt. Letztlich sollte der Vertriebsprozess so organisiert sein, dass neben dem aktuellen Quellcode auch sämtliche Lizenztexte, Urheberrechtshinweise und Gewährleistungsausschlüsse den Kunden zugänglich gemacht werden.

PUNKT 6

Open Source Policy

Genauso wie OSS Compliance im Unternehmen unerlässlich ist, ist auch die Etablierung einer unternehmensweiten Open Source Policy unverzichtbar. Entwickler müssen dafür sensibilisiert werden, was im Unternehmen im Hinblick auf Open Source Komponenten erlaubt ist und was nicht.


Quelle: https://www.sonatype.com/hubfs/Whitepaper-LicensingCompliance-DACH-2020/Whitepaper-LicensingCompliance-DACH-2020-PDF.pdf/

PUNKT 7

Open Source Policy

Genauso wie OSS Compliance im Unternehmen unerlässlich ist, ist auch die Etablierung einer unternehmensweiten Open Source Policy unverzichtbar. Entwickler müssen dafür sensibilisiert werden, was im Unternehmen im Hinblick auf Open Source Komponenten erlaubt ist und was nicht.

PUNKT 8

Bill of Materials — Inventur der einzelnen Artefakte

Um genau bestimmen zu können, welche Komponenten sich in welcher Applikation befinden, benötigt man für jeden Build eine „Bill of Materials“, also quasi eine Inventurliste der einzelnen Komponenten in jeder Applikation. Jede Komponente muss dokumentiert, dessen Lizenztext exportiert und mit der Applikation zugänglich gemacht werden. Dies ist ein Prozess, der aufgrund der vielen Abhängigkeiten mittels manueller Recherche nicht zu leisten ist und für den man daher automatisierte Tools benötigt. Diese Tools bedürfen jedoch zuverlässiger Informationen. Diese stellt das aus mehr als 100 Datenforschern bestehende Team bei Sonatype zur Verfügung, die jedes einzelne Artefakt manuell verifizieren.

PUNKT 9

Sicherheitsstandards beachten

Neben der aktuellen Bestandsaufahme der in der Software verwendeten Open-Source-Komponenten, sollte ein Prozess zur Identifizierung bekannter Schwachstellen in diesen Open-Source-Komponenten etabliert werden. Dazu ist es unerlässlich, die OpenSource Komponenten entlang des gesamten Software Delivery Lifecycle zu überwachen, sowie Richtlinien und Prozesse zur unmittelbaren Behebung von Schwachstellen anzuwenden, sobald diese bekannt werden. 


Für Entwickler konzipiert.

Wir von Sonatype glauben, dass Entwickler ihre Zeit für Innovationen verwenden sollten – und nicht dafür, mühseligen Sicherheitsanforderungen zu entsprechen, Verdächtiges aufzuspüren und Falschmeldungen zu Open-Source-Schwachstellen nachzugehen.

 

Deshalb möchten wir, dass Nexus so funktioniert, wie Sie gerne arbeiten möchten. Dank intelligenter Open-Source-Sicherheitskontrollen, die in Ihre Lieblingstools integriert sind, können Sie mühelos Schwachstellen finden und beheben – und so innovativ bleiben.


Vulnerability Scanner

NexusVulnScanner_Vertical3x.png

Ist Ihre App solide? Testen Sie kostenlos den Nexus Vulnerability Scanner und finden Sie es heraus.

  • Die durchschnittliche Anwendung besteht aus 106 Open-Source-Komponenten
  • Eine übliche Anwendung enthält 23 bekannte Sicherheitslücken
  • Die meisten Anwendungen weisen mindestens 8 GPL-lizenzierte Komponenten auf
  • Viele der verwendeten Komponenten sind veraltet, wenig verbreitet und werden nicht mehr unterstützt

REPOSITORY

NexusRepo_Icon3x.png

Ihre verlässliche Informationsdatenquelle für Software-Artefakte.

  • Support aller gängigen Komponentenformate
  • Automatische Identifikation von schadhaften Elementen
  • Permanent einsatzbereit für Continuous Delivery und Bereitstellung
  • Verlassen Sie sich auf die Unterstützung von Weltklasse-Experten

Lifecycle

NexusLifecycle_Icon3x.png

Präzise Schwachstellen-Daten auf einen Blick.

  • Definieren Sie Richtlinien für Open-Source-Komponenten nach Organisation, Team und Anwendungstyp
  • Setzen Sie Richtlinien in Ihrer gesamten DevOps-Pipeline automatisch und dem Kontext entsprechend durch
  • Visualisieren Sie Komponentendaten kontinuierlich in Ihren favorisierten Tools (einschließlich Nexus und Artifactory)
  • Kombinieren Sie Komponentendaten mit internen Apps, indem Sie unterstützte Rest APIs verwenden

NextGen Firewall

NexusFirewall_Icon3x.png

Gebieten Sie Open-Source-Risiken frühzeitig Einhalt.

  • Ermöglichen Sie eine kontinuierliche Prüfung und verhindern Sie, dass unerwünschte Komponenten verbreitet werden, indem Sie diese unter Quarantäne stellen
  • Verhindern Sie, dass gefährdete Java-, JavaScript-, .Net-, PyPI-, RubyGems-, Go- und RPM-Komponenten in Ihre Pipeline gelangen
  • Schließen Sie riskante Komponenten automatisch aus Ihren Anwendungen aus
  • Lassen Sie sich benachrichtigen, wenn unerwünschte Komponenten in Quarantäne verschoben werden

Advanced Legal Pack - Lifecycle ADD-ON

Für die Einhaltung Ihrer rechtlichen Verpflichtungen bedarf es zeitaufwändiger, manueller Prozesse. Wahrscheinlich investieren Sie jedes Jahr Hunderte, wenn nicht Tausende Stunden (und Euros), nur um die erforderlichen juristischen Daten zu sammeln – ganz zu schweigen von dem Zeitaufwand, der anschließend bei der Überprüfung dieser Informationen anfällt. Mit dem Advanced Legal Pack von Sonatype reduzieren Sie die Komplexität des gesamten Compliance-Prozesses.

  • Generiert Attributionsberichte automatisch
  • Workflows zur Einhaltung von Rechtsvorschriften
  • Ihnen werden Daten zur Verfügung gestellt, die Sie benötigen um fundierte und rechtliche Entscheidungen zu treffen
  • Tool zur Überprüfung von Lizenzverpflichtungen

Infrastructure as Code - Lifecycle ADD-ON

Zusätzlich zur Auswahl und Konfiguration der richtigen Open-Source-Komponenten sind Entwickler zunehmend auch für das Schreiben der Codes zur Bereitstellung und Konfiguration ihrer Cloud-Infrastruktur verantwortlich. Zusammen mit Nexus Lifecycle bietet der Infrastructure as Code (IaC) Pack Ihnen alle Informationen, die Sie brauchen, um sowohl die besten Open-Source-Komponenten auszuwählen als auch die Sicherheit Ihrer Cloud-Infrastruktur zu gewährleisten.

  • Erkennen Sie Probleme in Terraform-Konfigurationen bevor sie in der Produktion
  • Beseitigen Sie Cloud-Fehlkonfigurationen
  • Bewährte Praktiken der Cloud-Sicherheit
  • Cloud und Open Source Sicherheit gemeinsam an einem Ort

Auditor

NexusAuditor_Icon3x.png

Verschaffen Sie sich einen Überblick über die Qualität der in Ihren Produktions-Anwendungen verwendeten Open-Source-Komponenten.

  • Erhalten Sie detaillierte Ergebnisse über Komponentendaten bis hin zur transitiven Abhängigkeit
  • Entwickeln Sie Richtlinien auf Basis vorhandener Regeln oder Vorschriften
  • Schlüsseln Sie Ergebnisse genau auf, um Probleme im Zusammenhang mit Sicherheit, Lizenzen und Qualität zu erkennen
  • Überwachen Sie Anwendungen kontinuierlich, um neue Komponentenprobleme aufzuspüren

DepShield

NexusDepShield_Icon3x.png

Automatische Erkennung von Open-Source-Schwachstellen.

Identifizieren Sie automatisch Schwachstellen innerhalb von Open-Source-Abhängigkeiten.

 

Sonatype + GitHub = Sicheres Open Source

  • Powered by Sonatype OSS Index.Kostenlos für öffentliche und private Repositorys
  • Kontinuierliche Überwachung von Projekten und automatische Erstellung von Issues bei Sicherheitslücken
  • Für Apache Maven-, Node.js npm- und Go-Projekte verfügbar

Vulnerability Scanner

Scannen Sie Ihre Anwendung in 3 einfachen Schritten.

 

1. Laden Sie den Nexus Vulnerability Scanner herunter.

Schicken sie das Formular ab, um den Nexus Vulnerability Scanner lokal herunterzuladen.

 

2. Wählen Sie die Anwendung aus, die Sie scannen möchten.

Scannen Sie eine eigene Anwendung oder wählen Sie eine unserer Beispiel-Apps aus, um sich von der Leistungsfähigkeit des NVS zu überzeugen.

 

3. Prüfen Sie Ihre gesamte Software Bill of Materials.

Wir haben Ihnen per E-Mail einen Link zu Ihrer Software Bill of Materials (SBOM) gesendet. So können Sie sich ein Bild von Richtlinienverstößen sowie Sicherheitsproblemen machen und eine Lizenzanalyse durchführen, um festzustellen, welchen Open-Source-Risiken Sie ausgesetzt sind.

 

Wichtiger Hinweis:

Bei der Ausführung von NVS können Sie entweder eine Beispielanwendung (zum Herunterladen hier klicken: https://de.sonatype.com/hubfs/URLs/WebGoat-6.0.1.war) oder Ihre eigene Anwendung überprüfen lassen.  Bei der Überprüfung Ihrer eigenen Anwendung wird weder Ihr Quell- noch Ihr Binärcode in irgendeiner Weise offengelegt.


Nexus IQ (Für Teams ab 20 Entwickler)

Holen Sie die maximale Sicherheit für Ihr gesamtes Entwickler Team aus der Kombination Nexus Firewall und Nexus Lifecycle. Unsere Empfehlung ist es mit einer Vorabinvestition sich gegen nachträgliche Klagen abzusichern.

Nexus IQ Small Business (Für Teams bis 20 Entwickler)

Auch Anwendungen kleiner Firmen sind nicht vor Attacken sicher. Somit gilt auch für Unternhemen mit kleineren Teams das Thema Compliance an erster stelle. Denn gerade wenn kleiner Unternehmen von einem Hack betroffen sind, kann eine Klagewelle Ihre Existenz ins Wanken bringen.

Nexus IQ Lifecycle Foundation (Nur für Teams bis maximal 250 Entwickler)



Weitere Quellen

Sonatype Blog
Sonatype auf Twitter
Sonatype auf Facebook

Anfragen

Aktuelle Preisanfragen können Sie direkt unter der Mailadresse sales@swnetwork.de ersuchen oder über das Kontakformualar an uns senden.

Bei fachlichen Fragen bitten wir Sie ebenfalls uns über die oben genannten Kanäle zu kontaktieren.

Ein Mitarbeiter der SWNetwork GmbH wird sich dann zeitnah bei Ihnen melden.

Ihre SWNetwork GmbH