SOFTWARE SUPPLY CHAIN MANAGEMENT TEIL 2

Die Anfänge der komponentenbasierten Software-Entwicklung

Noch in den 2000er Jahren war Open Source ein Platzhalter und wurde heiß diskutiert. Mittlerweile gibt es jedoch kaum noch Zweifel an der Funktionsfähigkeit oder dem praktischen Nutzen. Stattdessen definiert Open Source nun die gesamte Branche, und diese Entwicklung scheint sich nicht zu verlangsamen.

Der Bereich Komponenten-Software wächst mit mehr als 2,2 Billionen Downloads in den 4 wichtigsten Open-Source-Programmiersprachen im Jahr 2021 immer noch rasant. Allein in Maven Central wurden 497 Milliarden Downloads für Java verzeichnet.

Teil2-1

Jährliche Downloads von Open-Source-Java-Komponenten insgesamt.

Die Realität ist, dass Software nicht nur geschrieben, sondern aus Einzelteilen zusammengesetzt wird. Sogar Linux – eines der erfolgreichsten Produkte aus dem Open-Source-Bereich – wurde von Anfang an mit Komponenten-Software-Projekten aufgebaut. Das moderne Linux ist sowohl ein Bestandteil der Software Supply Chain als auch eine Komponente für andere Projekte.

Heutzutage wird Software selten von Grund auf neu erstellt. Und warum sollten Entwickler bei der Lösung ihrer Entwicklungsaufgaben nicht auf frei verfügbare, qualitativ hochwertige Software zurückgreifen? Es ist, als würden 1.000 Personen in Ihrem Team arbeiten, anstatt zehn. Entwicklungsteams verlassen sich auf Komponenten von Drittanbietern und Open Source, um schneller Code bereitzustellen und Innovationen zu entwickeln, ohne jedes Mal das Rad neu erfinden zu müssen. 

Solche Komponenten werden als „Abhängigkeiten“ bezeichnet, und jede Abhängigkeit birgt potenzielle Risiken in Form von Sicherheitslücken, Lizenz- oder Qualitätsproblemen. Viele Abhängigkeiten beruhen auf anderen Open-Source-Komponenten, die auch als „transitive Abhängigkeiten“ bezeichnet werden, wodurch es schwieriger wird, die ursprünglichen Risikoquellen zu identifizieren.

Warum sollten Entwickler bei der Lösung ihrer Entwicklungsaufgaben nicht auf frei verfügbare, qualitativ hochwertige Software zurückgreifen? Es ist, als würden 1.000 Personen in Ihrem Team arbeiten, anstatt zehn.

Arten von Software-Abhängigkeiten

In Hinblick auf die Software Supply Chain muss man sowohl die Komponenten als auch die Unterkomponenten beachten. Das entspricht vom Prinzip her einem Automotor, der aus Tausenden von Teilen besteht, von denen jedes aus seiner eigenen Software Supply Chain stammt.

  • Direkte Abhängigkeiten – Software-Entwickler fügen Open-Source-Komponenten häufig direkt zur Codebasis (oder zum Abhängigkeitsbaum) hinzu. Darüber hinaus wird eine direkte Abhängigkeit vom Programm selbst referenziert und als „Parent“ (übergeordnetes Element) bezeichnet. Solche direkten Abhängigkeiten steuern, wer ihre untergeordneten Elemente sind (transitive Abhängigkeiten), und ob sie überhaupt welche haben oder nicht.
    direkte-Abhängigkeiten
  • Deklarierte Abhängigkeiten - In Programmiersprachen, die Paketmanager verwenden, können Software-Entwickler deklarieren, dass eine Komponente in einem vom Build-Prozess verwendeten Manifest erforderlich ist. Das führt dazu, dass das Build-Tool die Komponente aus einem binären Repository wie Nexus Repository importiert. Weitere Informationen zu Paketmanagern und binären Repositorys folgen später! 
    declared-dependencies.png
  • Transitive Abhängigkeiten – Diese treten auf, wenn eine deklarierte Abhängigkeit erfordert, dass zusätzliche Open-Source-Komponenten ordnungsgemäß ausgeführt werden. Diese sind oft problematisch, da Schwachstellen oder Qualitätsprobleme auf dieser Ebene häufig nicht gemeldet oder untersucht werden.  Da sie für Entwickler weniger zugänglich sind, ist es schwierig, Probleme zu beheben.
    transitive-Abhängigkeiten

Durch die Verwendung solcher Drittanbieterkomponenten in ihren Anwendungen übernehmen Unternehmen die Verantwortung für Code, den ihre Teams nicht geschrieben haben. Ebenso sollte man transitive Abhängigkeiten als Teil Ihres InnerSource-Codes (oder des Codes, den Sie selbst wie Open Source in Paketen anbieten) betrachten. Das Risiko, das in einer Anwendung durch Open-Source-Software und InnerSource entsteht, kann durch Software Composition Analysis (SCA) kontrolliert und verhindert werden.

Darauf werden wir noch detaillierter eingehen, wenn wir in Teil 4: Die Grundlagen des Software Supply Chain Managements die Abhängigkeitsverwaltung und SCA erläutern.

Artefakt-Verwaltung und Repositorys

Die Software Supply Chain lässt sich anhand des Prozesses verstehen, mit dem Software-Komponenten gesammelt, verwaltet und verteilt werden. Da wir über komponentenbasierte Software sprechen, wollten wir etwas tiefer gehen. Software ist mehr als nur Quellcode – sie ist eine Sammlung von Elementen, die als Artefakte bezeichnet werden.

Was ist ein Artefakt?

Das Wort „Artefakt“ erinnert eher an eine Antiquität, die in einem Museum aufbewahrt wird. Aber der Begriff kann auch allgemeiner die Produkte einer Person oder Gruppe bezeichnen. Für Software-Entwickler erfassen und identifizieren Artefakte die verschiedenen Teile der Software-Erstellung, einschließlich Quellcode, Anwendungsfälle, Modelle, Anforderungen, Designdokumente und mehr.

[Artefakte] helfen anderen Entwicklern dabei, den Denkprozess hinter der Entwicklung einer Software zu erkennen. Damit lassen sich weitere Entscheidungen nun fundierter treffen und man kann die weitere Vorgehensweise besser verstehen.

— BAELDUNG.COM

Repository Manager

Repository Manager sind Server, die Artefakte speichern und abrufen. Wenn Sie Software schreiben, sind Sie häufig auf externe Bibliotheken angewiesen. Wenn Sie ein System entwickeln, um eine Rakete in den Weltraum zu schicken, benötigen Sie möglicherweise ein Artefakt, das Funktionen zur Berechnung von Schwerkrafteffekten bietet. Wenn Sie eine Website erstellen, verwenden Sie wahrscheinlich ein Framework, das den Besuchern Text und Bilder anzeigt.

Öffentliche Repositorys (Upstream)

Repositorys wie Maven Central und npm dienen als globale Upstream-Bibliotheken, die alle Open-Source-Komponenten speichern.  Diese öffentlich sichtbaren Server haben zig Millionen Nutzer auf der ganzen Welt, aus Hunderttausenden von Open-Source-Projekten. Sie sind so etwas wie eine moderne „Bibliothek von Alexandria“, die als Zentrum für Wissen und Lernen dienen, allerdings für Open-Source-Komponenten.  

Solche Dienste reduzieren den Arbeitsaufwand für die Verteilung von Artefakten an Millionen von Entwicklern erheblich.

Teil2-5

Vor dem Aufkommen öffentlicher Repositorys mussten Benutzer Abhängigkeiten manuell aktualisieren. Open-Source-Projekte mussten dann versuchen, die Öffentlichkeit über eine neue Software-Version zu informieren. Heute ist die weltweite Veröffentlichung neuer Open-Source-Komponenten kein Problem mehr.

Binäre Repository Manager (Caching-Dienst)

Im Gegensatz zu den anderen Repository Managern werden binäre Repository Manager von einzelnen Gruppen oder Teams für den eigenen Gebrauch eingerichtet.  Sie erfüllen wichtige Funktionen im Rahmen eines modernen Software Development Lifecycle.

Bewahren Sie eine Kopie auf

Diese Manager fungieren als „Proxys“ oder Backups für Repositorys wie Maven Central, npm und andere Repository Manager. Wenn eine neue Komponente benötigt wird, rufen die Manager sie aus dem Repository ab und cachen eine Kopie lokal zur späteren Verwendung. Das ist wichtig, denn selbst kurze Ausfälle von Repositorys können Entwicklern enorme Probleme bereiten. Entwickler sparen sowohl Bandbreite als auch Abrufzeit bei der Verbindung mit dem Artefakt-Management-Storage. 

Außerdem verschwinden Komponenten manchmal aus gehosteten Repositorys. Das ist ein großes Risiko für all Ihre Anwendungen, insbesondere für ältere, die weiter unterstützt werden. Eine lokale Kopie des Repositorys reduziert das Risiko. Und da die Kopie lokal ist, können Sie sie direkt verwalten und an die Bedürfnisse Ihres Unternehmens anpassen. 

Das ist besonders für Entwicklungsteams in Unternehmen von entscheidender Bedeutung, die oft aus vielen Personen bestehen und geographisch weit verteilt sind. Eine effiziente Infrastruktur und gemeinsame Auffassungen über die Entwicklung von Software ermöglichen eine schnelle Zusammenarbeit.

Repository Manager können auch als Hosts für interne Artefakte dienen, etwa für eine benutzerdefinierte Datenbankeingabe oder eine unternehmensspezifische Compliance-Prüfung.  Diese fungieren als „Single Source of Truth“ für die in Ihren Build-Prozessen verwendeten Binärdateien. Ein Beispiel ist Sonatypes Nexus Repository

So wie öffentliche Repositorys einer ganzen Welt von Software-Entwicklern eine effizientere Arbeitsweise ermöglichen, kann man mit einem internen binären Repository Manager eine effiziente Zusammenarbeit zwischen Entwicklern und Teams gewährleisten. Wenn ein Team eine Bibliothek entwickelt, die von einem anderen Team verwendet wird, kann es mithilfe eines internen Repository Managers Software-Releases intern als Teil seiner InnerSource-Tools verbreiten. Wenn Ihre Entwicklungsteams Anwendungen für eine Betriebsgruppe bereitstellen, können sie einen Repository Manager verwenden, um Endprodukte gemeinsam zu nutzen.

Selbst für kleine Teams lassen sich mit zwischengespeicherten Repositorys Änderungen schneller durchführen, die benötigte Bandbreite reduzieren und bestimmte Kontrollmöglichkeiten einführen, um zu steuern, welche Software aus dem Development Lifecycle ausgeschlossen werden soll.

Container

Open Source von Drittanbietern wird in fast allem verwendet, was heute an Software entwickelt wird – in eingebetteten Tools, Desktops, Cloud-Anwendungen, virtuellen Maschinen und mehr. Eines der offensichtlichsten Ergebnisse der Software Supply Chain ist jedoch die Containerisierung. Die Geschwindigkeit der Entwicklung und Bereitstellung, die durch eine konsistente Umgebung unterstützt wird, verschafft Container-Software in vielerlei Hinsicht einen Vorsprung.

Es ist kein Zufall, dass Pressemeldungen zu dem Thema oft mit Bildern von Containerschiffen unterlegt werden.

„Die Container-Technologie hat ihren Namen aus der Schifffahrtsbranche. Anstatt jedes Produkt einzeln zu versenden, werden die Waren in Stahlcontainer verpackt, die darauf ausgelegt sind, mit einem Kran am Dock verladen zu werden. Außerdem passen sie perfekt in das Schiff, das für die Standardgröße des Containers bemessen ist. Kurz gesagt: Durch die Standardisierung des Prozesses und die Zusammenführung einzelner Elemente kann der Container als Einheit transportiert werden. Dadurch kostet es weniger. (TechRadar)“

Teil2-6a

Vorteile und Akzeptanz

Container ermöglichen das einfache Teilen und Bereitstellen von Apps mit:

  • Einer konsistenten Umgebung und konsistenten Tools
  • Berechenbaren Build-Tools
  • Einer schnelleren Bereitstellung

Container können als Schnittstelle zwischen Entwicklung und IT-Betrieb fungieren. Und bei ordnungsgemäßer Konfiguration kann das Betriebsteam Container verwenden, um Umgebungen zusammenzustellen, ohne die Sicherheit zu beeinträchtigen.

Aufgrund dieser Vorteile ist die Nutzung von Container-Software zur Bereitstellung von Software seit 2013 explodiert. In unserem State of the Software Supply Chain Report 2020 haben wir bereits darüber berichtet.

„Pulls aus Container-Images haben im Januar die Marke von 8 Milliarden geknackt. Das bedeutet, dass die Zahl der Pulls aus dem Repository auf das gesamte Jahr 2020 hochgerechnet bei über 96 Milliarden liegen wird. Um der Nachfrage gerecht zu werden, stellten die Anbieter im Lauf des vergangenen Jahres 2,2 Millionen neuer Images in DockerHub zur Verfügung – ein Anstieg von 55 % seit der Veröffentlichung unseres letzten Berichts.“ 

Es gibt keine Anzeichen dafür, dass sich diese Entwicklung verlangsamen wird. Gartner prognostiziert für das Jahr 2022, dass 75 % der Unternehmen weltweit Anwendungen aus Containern ausführen werden, gegenüber 30 % im Jahr 2020.

Da Container auf dieselben Software-Abhängigkeiten angewiesen sind, mit der auch andere Software arbeitet – nur mit schnellerem Durchsatz – werden sie dadurch zu direkten Angriffszielen. Deswegen können Angriffe auf Container auf umfassendere Angriffe auf die Software Supply Chain hindeuten. Und effektive Sicherheit bedeutet, dass man nach Schwachstellen in den Komponenten sowie nach Compliance-Problemen und Fehlkonfigurationen Ausschau halten muss.

Container können als Schnittstelle zwischen Entwicklung und IT-Betrieb fungieren. Und bei ordnungsgemäßer Konfiguration kann das Betriebsteam Container verwenden, um Umgebungen zusammenzustellen, ohne die Sicherheit zu beeinträchtigen.

Die Lösung für dieses Problem und der Eckpfeiler eines guten Sicherheitssystems ist die Fähigkeit, Schwachstellen in allen Phasen des SDLC zu erkennen und zu beheben. Dazu gehören Build-, Registry- und Produktionsumgebungen.

Komponentenlizenzierung

Ganz einfach ausgedrückt: Eine Software-Lizenz ist eine verbindliche Vereinbarung zwischen dem Ersteller der Software und dem Benutzer, die festlegt, wie die Software verwendet werden kann. In der Regel erlaubt die Lizenz dem Benutzer, die Komponente zu lesen, zu ändern und zu verwenden, sofern er einige Regeln befolgt.

Wenn Software als „Open Source“ bezeichnet wird, bedeutet das, dass der Quellcode anderen zum Ansehen und Lesen zur Verfügung gestellt wird. Eine Open-Source-Lizenz ist einfach eine Lizenz, die festlegt, dass die Software Open Source ist – aber wie bereits erwähnt, bedeutet das normalerweise nicht, dass sie immer und überall frei verwendet werden kann. 

In der Entstehungsphase von Open-Source-Software-Komponenten war es einfach, die Lizenzbedingungen einzuhalten, da es nur wenige gab und sie normalerweise zu einer kleinen Gruppe gehörten.  Mit der zunehmenden Verbreitung komponentenbasierter Software hat sich die Lizenzierung jedoch zu einem komplexen Thema entwickelt. Alleine in Maven Central verteilen sich 95 % der Komponenten auf 17 verschiedene Lizenzen, und die verbleibenden 5 % der Komponenten auf 307 weitere Lizenzen. 

Da es in einer typischen Software Supply Chain Hunderte solcher Komponentenlizenzen gibt, lässt sich leicht erkennen, wie Komplikationen entstehen.

Teil2-7

Compliance mit Komponentenlizenzen

Der Schwerpunkt der Lizenz-Compliance liegt auf der Nutzung des Richtlinienmanagements, um sicherzustellen, dass Entwickler Komponenten auswählen, die das rechtliche Risiko mindern. Viele Open-Source-Komponenten sind jedoch mit zusätzlichen Anforderungen verbunden. Diese können auch gesetzliche Verpflichtungen umfassen. Manchmal muss lediglich auf den Urheber verwiesen werden, und in anderen Fällen muss der geänderte Quellcode an die Community freigegeben werden.

Selbst die gängigsten Verpflichtungen können schwierig sein. „Attribution“-Lizenzen – bei denen der Lizenztext, ein Hinweistext, der Urheber, die Mitwirkenden und/oder der Quellcode einer OSS-Komponente angegeben werden müssen – werden schnell kompliziert, wenn man Hunderte von Abhängigkeiten hat. Tatsächlich enthalten Anwendungen durchschnittlich über 128 Abhängigkeiten, und um alle erforderlichen Daten zu sammeln, müssen bis zu 58 Arbeitsstunden aufgewendet werden. (weitere Informationen)

Auch hier ist Automatisierung der Schlüssel, um zu vermeiden, dass kompetente Entwickler mit Lizenzsammlungs- und Aktualisierungsaufgaben belastet werden.

Sonatype Envelope

Möchten Sie sich selbst von Nexus-Produkten überzeugen?