SOFTWARE SUPPLY CHAIN MANAGEMENT TEIL 4

Die Grundlagen verstehen

Entwicklungsteams müssen Sicherheitsrisiken reduzieren, die Integrität und Compliance der Software gewährleisten und gleichzeitig den Entwicklungsablauf verbessern. Jetzt wissen wir, was eine Software Supply Chain ist und wie sich die Branche verändert. Wie laufen all diese Faktoren im Software Supply Chain Management zusammen?

Zusammenfassung der Richtlinien für die Supply Chain

In diesem Abschnitt werden wir vor allem auf der Analyse der Supply Chain in der Fertigung aus Teil 1 und auf den vier Prinzipien von Deming aufbauen. Diese gelten sowohl für gewöhnliche Lieferketten als auch für Software Supply Chains. 

Eine kurze Zusammenfassung, auch mit Bezug auf die Software-Entwicklung: 

  • 1. Bessere und weniger Lieferanten nutzen 
  • 2. Hochwertige Teile von diesen Lieferanten verwenden 
  • 3. Fehler frühzeitig beheben und bekannte Fehler niemals an nachgelagerte Instanzen weitergeben
  • 4. Transparenz schaffen und verfolgen, was man wo verwendet

Teil-4-1

Jetzt erklären wir, wie das mit dem Software-Entwicklungsprozess zusammenhängt.

Notwendigkeit einer fortlaufenden Automatisierung

Die Branche und die Welt insgesamt kommen mit dem Verbrauchsvolumen und dem riesigen Ökosystem von Lieferanten, von denen man seine Komponenten beziehen kann, immer besser zurecht. Wenngleich bestimmte manuelle Überprüfungen zumindest teilweise bleiben werden, macht die riesige Menge an Artefakten es einfach unmöglich, sie manuell zu überprüfen, um ihren Zustand zu bestimmen. Unabhängig davon, welchen Teil der Software Supply Chain man betrachtet, ist Automatisierung erforderlich, um Probleme im großen Maßstab zu lösen. Unternehmen, die solche Maßnahmen zu zögerlich ergreifen, werden wahrscheinlich zurückfallen.

Ebenso wie traditionelle Lieferketten in der Fertigung sich der Automatisierung zugewandt haben, müssen die Software-Entwicklungsteams denselben Ansatz verfolgen. Informationen über die Lieferanten und die Qualität und Sicherheit ihrer Projekte müssen den Entwicklern bereits bei der Auswahl der Komponenten zur Verfügung stehen, und zwar kontinuierlich während des gesamten Entwicklungszyklus. Sie müssen ständig aktualisiert werden, sobald die Anwendung in Produktion ist. 

Die Automatisierung in den Bereichen Testing, Build und Bereitstellung hat erhebliche Leistungsvorteile mit sich gebracht. Auch die Investitionen in die Automatisierung der Supply Chain mit Software haben die Effizienz und die Risikokontrolle deutlich verbessert. Das Entwicklungspotenzial eines Unternehmens kann mit Automatisierung vollständig ausgeschöpft werden. Selten gibt es solche Gelegenheiten, Geschwindigkeit, Effizienz, Sicherheit und Qualität gleichzeitig zu steigern.

Unabhängig davon, welchen Teil der Software Supply Chain man betrachtet, ist Automatisierung erforderlich, um Probleme im großen Maßstab zu lösen.

1. Bessere und weniger Lieferanten nutzen

Wie auch in der traditionellen Fertigung liefern nicht alle Anbieter Teile vergleichbarer Qualität und Integrität. Untersuchungen zeigen, dass bestimmte Open-Source-Projekte restriktive Lizenzen und anfällige Unterkomponenten verwenden. Andere Projekte gehen deutlich gründlicher vor, um die Gesamtqualität ihrer Komponenten zu optimieren. Oft ist jedoch unklar, wer genau die Open-Source-Komponenten erstellt, die ein Entwickler verwenden möchte.

Darüber hinaus ist es erschreckend, von wie vielen Lieferanten Unternehmen Komponenten beziehen. Im Bericht „State of the Software Supply Chain 2020“ haben wir festgestellt, dass Betriebe für Unternehmensentwicklung im Durchschnitt 373.000 Open-Source-Komponenten pro Jahr heruntergeladen haben. Diese Downloads stammten im Durchschnitt aus 3.552 Open-Source-Projekten (oder Lieferanten).

Teil-4-9

Nicht zuletzt werden Open-Source-Projekte, sobald sie einmal verfügbar sind, niemals aus dem Verkehr gezogen. Das unterscheidet sie von den Produkten physischer Lieferanten in herkömmlichen Supply Chains. Und daher kann es passieren, dass Entwickler versehentlich veraltete Projekte weiter verwenden – sogar jene, die von den Erstellern gar nicht mehr gepflegt werden.

Einige Überlegungen zu den Teams hinter diesen Projekten, können im Nachhinein viel Zeit und Mühe sparen.

Überprüfungsprozess für Lieferanten und Bewertung der Projektsicherheit 

Die Wahl eines Open-Source-Projektanbieters sollte im Unternehmen als wichtige strategische Entscheidung angesehen werden. Den Lieferanten (ein Open-Source-Projekt) zu wechseln, ist weitaus aufwendiger als der Austausch einer bestimmten Komponente. Wie auch herkömmliche Lieferanten haben Open-Source-Projekte gute und schlechte Vorgehensweisen, die sich auf die Gesamtqualität ihrer Komponenten auswirken.

Herkömmliche Supply Chains wählen absichtlich bestimmte Teile von zugelassenen Lieferanten aus. Sie stützen sich auch auf formalisierte Beschaffungsmethoden. Dadurch kann sich das Unternehmen auch darauf konzentrieren, weniger Lieferanten zu nutzen.

Diese Praxis in die Entwicklung einzubeziehen, verbessert die Qualität, da die Entwickler weniger den „Kontext wechseln“ und nicht mehr ständig zwischen Aufgaben hin- und herspringen müssen. Sie können sich besser auf weniger Themen konzentrieren. Das beschleunigt auch die durchschnittliche Zeit bis zur Behebung, wenn Defekte entdeckt werden.

Automatisierung_animiert-breit

Im Gegensatz dazu verlassen sich Entwicklungsteams häufig auf eine ungeprüfte Vielfalt von Angeboten, bei der jeder Entwickler bzw. jedes Entwicklungsteam seine eigenen Entscheidungen zur Beschaffung treffen kann. Der Verwaltungsaufwand der bereits erwähnten 3.552 Lieferanten zieht auch die Entwicklung in Mitleidenschaft. Er steht im Widerspruch zu ihrem Bedürfnis, im Rahmen von Agile-, Continuous-Delivery- und DevOps-Praktiken schneller zu entwickeln. 

Viele Teams entscheiden sich für Software-Projekte, mit denen ihre Teams vertraut sind oder die in einer bestimmten Kategorie am beliebtesten sind. Die Analyse der Lieferanten in unserem Bericht 2021 ergab, dass die Beliebtheit ein schlechter Qualitätsindikator ist, da 29 % der beliebten Projekte mindestens eine bekannte Sicherheitslücke aufweisen. Bei Projekten mit geringerer Beliebtheit beträgt dieser Wert im Durchschnitt 6,5 %. Ob dies auf die Aufmerksamkeit der Sicherheitsforscher oder auf andere Faktoren zurückzuführen ist, dieser große Unterschied erfordert eine genauere Analyse.

Eine Analyse beliebter Lieferanten im Jahr 2021 ergab, dass die Beliebtheit ein schlechter Qualitätsindikator ist.

Unseren Erkenntnissen zufolge gibt es einige wichtige Indikatoren, auf die man sich konzentrieren sollte:

  • 1. Bessere Update-Prozesse. Gemessen an der Mean Time to Update (MTTU), der durchschnittlichen Zeit, die erforderlich ist, bis ein Projekt auf Versionen seiner Abhängigkeiten reagiert. 
  • 2. Reife des Projekts. Ein Projekt, das seit mehreren Jahren aktiv entwickelt wird, ist wahrscheinlich stabiler.
  • 3. Anzahl der pflegenden Entwickler. Je mehr, desto besser. 
  • 4. Release-Häufigkeit. Zuverlässige Projekte commiten häufiger Code und veröffentlichen ihn auch häufiger. 
  • 5. Sicherheit, also weniger Schwachstellen.

Teil-4-10

Diese Attribute können Ihre Suche nach qualitativ hochwertigeren Open-Source-Software-Projekten vereinfachen und die Sicherheit Ihrer Software Supply Chain drastisch erhöhen, was wiederum technische Schulden und „Innovationssteuern“ reduziert.

WONACH SIE AUSSCHAU HALTEN SOLLTEN: Projekte, die von einer Gruppe engagierter und reaktionsschneller Entwickler verwaltet werden; mit klaren und aussagekräftigen Richtlinien für die Beiträge; und mit einer aktiven Community haben, deren Mitglieder regelmäßig zur Optimierung des Quellcodes beitragen.

VORSICHT BEI: Projekten, die seit mehreren Jahren nicht mehr aktualisiert wurden, insbesondere bei Projekten mit nur einer oder zwei pflegenden Personen, die nicht wirklich mit Benutzern interagieren und nicht zum Mitmachen einladen. Ein Projekt mit einem einzigen Commit könnte ein kurzfristiges Problem lösen, langfristig aber ernsthaft Sorgen bereiten.

2. Hochwertige Komponenten von diesen Lieferanten verwenden

Jetzt, wo Sie einen Lieferanten ausgewählt haben, könnte es den Anschein erwecken, als hätten Sie den schwierigen Teil weitgehend erledigt. So wie Maschinen, die mit Teilen hoher und niedriger Qualität hergestellt werden, gute oder schlechte Ergebnisse erzielen, sind einige Komponenten besser als andere – selbst von den qualitativ hochwertigen Lieferanten. 

Während einige in der Branche dies als „Versionsverwaltung“ bezeichnen, verwenden wir oft den Begriff „Abhängigkeitsmanagement“ (insbesondere „Mikroabhängigkeitsmanagement“, aber das werden wir zu einem späteren Zeitpunkt erläutern). 

Es gibt drei Gründe, warum das Abhängigkeitsmanagement (bzw. die Versionsverwaltung) zu einer immer wichtigeren Praxis im Management von Software Supply Chains wird:

  • 1. Sobald eine Komponente in einem öffentlichen Repository freigegeben wurde, bleibt sie für immer dort – auch nachdem viele neuere und sicherere Versionen eingeführt wurden.
  • 2. Die unglaubliche Geschwindigkeit, mit der neue Versionen von Abhängigkeiten oder Projekten veröffentlicht werden.
  • 3. Open-Source-Abhängigkeiten altern eher wie Milch und nicht wie Wein. Einfach ausgedrückt: Auch wenn Sie von Anfang an die richtige Version ausgewählt haben, wird das nicht immer so bleiben. 

Die durchschnittliche moderne Anwendung enthält 128 Open-Source-Abhängigkeiten, und ein durchschnittliches Open-Source-Projekt bringt 10 Mal pro Jahr neue Versionen heraus. Das zu verwalten, ist eine unmögliche Aufgabe für die zuständigen Teams, und genau deswegen ist Automatisierung so wichtig.

Die durchschnittliche moderne Anwendung enthält 128 Open-Source-Abhängigkeiten, und ein durchschnittliches Open-Source-Projekt bringt 10 Mal pro Jahr neue Versionen heraus, was für die zuständigen Teams kaum zu bewältigen ist.

Um zu verstehen, wie Sie auch in Zukunft die optimalen Komponenten in Ihrer Software Supply Chain auswählen können, haben wir 8 allgemeine Regeln zusammengestellt.  Diese bauen alle aufeinander auf: 

  • 1. Wählen Sie keine Alpha-, Beta- oder Milestone-Version. Das bedeutet lediglich, dass Sie keine Version auswählen sollten, die sich in der Testphase befindet und möglicherweise noch nicht für den Einsatz bereit ist. 
  • 2. Vermeiden Sie ein Upgrade auf eine anfällige Version, selbst wenn es die neueste Version ist. Das scheint einfach zu sein, aber manchmal gibt es keine geeignete Option für Ihre Anforderungen, was uns zu Regel 3 führt. 
  • 3. Wenn mehr als eine Version eine bekannte Sicherheitslücke aufweist, führen Sie ein Upgrade auf die Version mit dem niedrigsten Schweregrad durch.
  • 4. Wenn das Open-Source-Projekt schnell hintereinander mehrere neue Versionen einer Komponente veröffentlicht hat, wählen Sie immer die neueste Version.
  • 5. Wenn Sie ein Upgrade durchführen und sich nicht von Anfang an für eine Version entscheiden, verwenden Sie einen Migrationspfad, den andere bereits gewählt haben. 
  • 6. Wählen Sie die Version, bei der Änderungen zu möglichst wenig defektem Code führen (anders gesagt: Wählen Sie die Version, die am wenigsten Probleme in der Anwendung verursachen wird.)
  • 7. Wählen Sie eine Version, die von der Mehrheit der Verbraucher verwendet wird. Aber im Rahmen des Zumutbaren: Wie bei den Lieferanten ist eine beliebte Komponente nicht immer die beste. 
  • 8. Wenn alle oben genannten Punkte zutreffen, wählen Sie einfach die neueste Version der Komponente. 

Wie bereits erwähnt, bauen diese 8 Regeln aufeinander auf.

Teil-4-3

Die neueste Version ist nicht immer besser

Manche Entwicklerteams versuchen, die Entscheidungsfindung im Abhängigkeitsmanagement zu automatisieren, indem sie Tools verwenden, die einfach die neueste Version einer Komponente abrufen, sobald sie verfügbar ist. Das ist ein wenig kurzsichtig, da neu nicht immer besser ist. 

Solche Updates können unbeabsichtigte Folgen haben, beispielsweise zu nicht geplanten Arbeiten führen oder unnötige Sicherheitsrisiken mit sich bringen – z. B. Malware-Injektion und Namespace-Confusion. Eine solche naive Update-Strategie für Abhängigkeiten kann frustrierend sein und lenkt unter Umständen ab. Laut dem Bericht „State of the Software Supply Chain 2021“ ist die optimale Version im Schnitt 2,7 Versionen älter als die NEUESTE.  Dies zeigt, dass die neueste Version nicht immer die beste Wahl ist, und unterstreicht, warum gut durchdachte Richtlinien für das Abhängigkeitsmanagement erforderlich sind, anstatt den Weg des geringsten Widerstands zu gehen. 

Wenn man nur die besten Komponenten in seiner Supply Chain verwenden möchte, entstehen die meisten Probleme aus solchen transitiven Abhängigkeiten, die tief in den Komponenten eingebettet und dadurch schwer zu erkennen sind. Wir werden weiter besprechen, wie Sie die erforderliche Transparenz schaffen können, sowie über Automatisierungstechniken, die nicht nur die Transparenz unterstützen, sondern auch eine angemessene Sicherheit, Wartungsfreundlichkeit und Integrität.

Wenn man nur die besten Komponenten in seiner Supply Chain verwenden möchte, entstehen die meisten Probleme aus transitiven Abhängigkeiten, die tief in den Komponenten eingebettet und dadurch schwer zu erkennen sind.

Die Rolle der Repository Manager im Abhängigkeitsmanagement

Repository Manager dienen als lokales Lager für alle Ihre Open-Source-Software-Komponenten und InnerSource-Komponenten. Sie bilden auch einen grundlegenden ersten Schritt in Richtung Abhängigkeitsmanagement im Rahmen Ihres umfassenderen Supply Chain Managements. Durch die lokale Speicherung von Komponenten erhalten Entwicklungsteams einen effizienteren und kontrollierteren Zugriff auf Komponenten innerhalb einer Organisation. Repository Manager werden verwendet, um die Erfassung, Nutzung, Freigabe und Bereitstellung von Komponenten, die aus öffentlichen Repositorys heruntergeladen wurden, sowie anderer interner Build-Komponenten und Artefakte zu optimieren. 

Sobald Komponenten in einem Repository Manager zwischengespeichert wurden, können Entwickler und ihre Entwicklungstools die Komponente lokal so oft wie nötig im gesamten Unternehmen abrufen, unabhängig davon, in wie vielen Anwendungen sie benötigt wird. Repository Manager unterstützen einmalige Downloads, die dann mehrfach benutzt werden, was die Beschaffungsmethoden verbessert.  Sie bilden daher einen grundlegenden Schritt zur Verbesserung der Leistung und Kontrolle von Komponenten oder Teilen in der gesamten Software Supply Chain.

Teil-4-4

Verbesserung der Quellcodequalität von Erstanbietern

Was auch immer in den nächsten zehn Jahren und darüber hinaus mit der Software Supply Chain passiert, wahrscheinlich werden Entwickler auch weiterhin Komponenten zusammenbauen und warten. Wie Unternehmen sich und ihr Produkt von der Konkurrenz abheben, beginnt in dieser Phase. Hier verbinden die Entwickler die verschiedenen Komponenten, über die wir gesprochen haben, miteinander und schreiben individuellen Code. Mit eben dieser „First Party“-Quellcode-Arbeit beginnt Ihr Unternehmen mit der Lösung von Kundenproblemen.

Die meisten Tools in diesem Bereich sind auf die Anforderungen der „agilen“ Entwicklung ausgelegt und konzentrieren sich in erster Linie auf die Kunden und ihre Bedürfnisse. Erfolgreiche Projekte werden in der Regel danach bewertet, ob sie Kundenanforderungen und -anfragen erfüllen oder nicht. Aber was ist mit den Features, die in allen Software-Projekten eine Rolle spielen, etwa Zuverlässigkeit, Geschwindigkeit und Sicherheit?  

Wenn es um alle Aspekte der Software geht – Lesbarkeit des Codes, Reaktionsfähigkeit, Wartungsfreundlichkeit, Zuverlässigkeit usw. –, dann sprechen wir von Codequalität.

Mit solcher „Erstanbieter“-Quellcode-Arbeit kann Ihr Unternehmen anfangen, Kundenprobleme zu lösen.

Transparenz_animiert-breit

Automatisierbare Codequalität

Viele Faktoren spielen bei der Automatisierung eine Rolle: Architektur, API-Design, Code-Stil, Auswahl von Bibliotheken und Best Practices für das Coding sind nur einige davon. Manche, beispielsweise Architektur und Design, erfordern Input von Menschen. Andere wiederum lassen sich mithilfe von Codeanalyse-Tools automatisieren. Mit den richtigen Tools lassen sich einheitliche Standards gewährleisten und Analysetools in den Entwicklungsprozess einbeziehen. Sie sind ein einfacher erster Schritt bei der Priorisierung der Qualität.

Die Komponenten, die Sie aus der Software Supply Chain auswählen, lohnen sich gar nicht, wenn Ihr eigener Code sie nicht effektiv nutzt. Tools zur Codequalität ermöglichen eine bessere Entwicklung in großem Maßstab und helfen bei der Verwaltung von Interaktionen mit Drittanbietersoftware, die Probleme für Ihre Software verursachen könnte. Dazu gehören Aspekte wie API-Best-Practices, der Informationsfluss und häufige Implementierungsfehler bei kryptographischen Bibliotheken.

3. Probleme frühzeitig beheben und bekannte Fehler niemals an nachgelagerte Instanzen weitergeben

Obwohl gemäß Branchenkonvention Open-Source-Komponenten als „upstream“ (vorgelagert) und Endbenutzer der Software als „downstream“ (nachgelagert) betrachtet werden, kann sich dieser Punkt auch auf Aufgaben beziehen, die weit vor der Testphase stattfinden.  Teams müssen vermeiden, bekannte Fehler innerhalb ihres eigenen Unternehmens weiterzugeben, sei es an Sicherheits- und Betriebsteams oder sogar an andere Entwickler. Und vor allem: nicht an Produktionsanwendungen.

Die Weitergabe von problematischer Software oder häufige Workarounds für fehlerhafte Tools sind eine weitere Form der technischen Schulden. Im Laufe der Zeit müssen diese Schulden in Form von Nacharbeiten und Refactoring gezahlt werden, in der Regel ungeplant und ungelegen.

Keine Software ist fehlerfrei, daher müssen die Teams nach bestem Wissen und Gewissen vorgehen, gehen aber selten auf Nummer sicher. Wenn sie durch begrenzte Ressourcen oder enge Fristen eingeschränkt werden, lassen Teams zu, dass umfangreiche Probleme an die nächste Stufe der Software Supply Chain weitergegeben werden.

Durch die Weitergabe problematischer Software oder häufiger Behelfslösungen für fehlerhafte Tools entstehen neue technische Schulden.

DevOps und DevSecOps

In diesem Dokument versuchen wir vor allem, zu verstehen und zu optimieren, wie externe Software-Abhängigkeiten funktionieren. Ebenso wichtig ist, wer später mit den Ergebnissen dieser Arbeiten zu tun hat: Ihre internen Mitarbeiter. Obwohl es von Unternehmen zu Unternehmen unterschiedlich sein kann, bestehen die meisten Teams aus drei spezialisierten Gruppen:

  • 1. Entwicklung – Schreiben und Erstellen der Software
  • 2. Betrieb – Bereitstellung und Verwaltung der Software
  • 3. Sicherheit – Prüfung auf Probleme in verschiedenen Phasen des Prozesses

Dies sind die Mitarbeiter, die Software-Produkte für Ihr Unternehmen zusammenstellen, testen und liefern. In den 2000er Jahren wurden kontinuierliche Anstrengungen unternommen, um die Agilität und Reaktionsfähigkeit in diesem Prozess zu verbessern. Dabei hat man sich vor allem auf Silos und Engpässe zwischen den Abteilungen konzentriert. Indem diese Arbeiten optimiert wurden, wurden mehr Überschneidungen zwischen Entwicklung und Betrieb geschaffen – ein Konzept, das allgemein als „DevOps“ bezeichnet wird.

Forrester Research sagt über DevOps:

DevOps bietet die objektiven Informationen – und den Einblick in diese Informationen –, die Unternehmen benötigen, um Entscheidungen über die Anwendungsbereitstellung zu treffen. Anstelle von regelmäßigen, subjektiven und zeitaufwändigen Statusberichten erhalten Unternehmen in Echtzeit Einblicke in den Anwendungszustand und den Fortschritt der Bereitstellung. Diese werden im Rahmen der Teamarbeit erfasst.

– FORRESTER RESEARCH

Der Erfolg und der Nutzen dieses Konzepts haben auch dazu geführt, dass Silos für die Sicherheit, die früher als Torstopper galten, abgebaut wurden, um „DevSecOps“ zu etablieren.

Wir können zwar nicht alle Aspekte erläutern, unter denen ein DevOps-Ansatz das Supply Chain Management Ihrer Software optimieren kann, aber dafür gibt es verfügbare Ressourcen.

Sicheres Coding, kontinuierliche Tests und „Shifting Left“ (Linksverschiebung)

Eine zentrale Säule von DevOps und DevSecOps ist der „Shift Left“, auch als „Start Left“ bezeichnet. Dieser Ausdruck beschreibt das Prinzip der frühzeitigen Prüfung und Überprüfung der Codequalität im Software Development Lifecycle (SDLC).

Einfach ausgedrückt: Der einfachste Weg zu einer höheren Software-Qualität ist, das Testen nicht bis zum Ende eines Prozesses hinauszuschieben. Da Software-Entwicklungsprozesse in Diagrammen meist von links nach rechts strukturiert sind, muss man Prozesse nach links verschieben („Shift Left“), damit sie zu einem früheren Zeitpunkt erfolgen. 

Teil-4-11

Obwohl jedes Entwicklungsteam anders und jeder Prozess einzigartig ist, besteht das Ziel darin, zu vermeiden, dass Test- und Sicherheitsaufgaben den Prozess verzögern, bevor die Software zum nächsten Schritt übergehen kann.  Diese Aufgaben in den Prozess einzubeziehen, ist eines der Hauptziele der Entwicklungen in den Bereichen DevOps, DevSecOps und Continuous Integration/Continuous Delivery.

Der Begriff „Shift Left“ ist zum Überbegriff für allgemein schnellere Entwicklungspraktiken geworden. Das Ziel besteht jedoch vor allem darin, seine Entwickler, die häufig an vorderster Front in Bezug auf Qualität, Sicherheit und Betrieb stehen, besser aufzustellen. 

 

Wenn wir bei Sonatype von „Shift Left“ reden, entspricht das voll und ganz Demmings Leitsatz: „Sie können die Qualität in Ihren Produkte nicht kontrollieren.“  Damit muss man schon zu Beginn des Prozesses anfangen.

4. Transparenz schaffen und verfolgen, was man wo verwendet

Es sind verschiedene Möglichkeiten entstanden, wie Unternehmen ihre Komponenten-Software nachverfolgen können, so haben sich Automatisierung und Standardisierung in diesem Bereich entwickelt. So wie reguläre Lieferanten eine Bill of Materials haben, die während eines Produktrückrufs geprüft werden kann, gibt es auch im Software-Bereich eine entsprechende Option für Audits und ähnliches.

Erstellen Sie eine Software Bill of Materials (SBOM)

Leser, die nach Möglichkeiten zur Behebung von Problemen mit der Software Supply Chain suchen, sollten hier ansetzen. Schließlich können Sie nichts tun, ohne vorher zu wissen, was in der eigenen Software enthalten ist. Gartner Research sagt hierzu:

„Um die Risiken von Open-Source-Software zu managen und zu mindern, müssen Führungskräfte im Sicherheits- und Risikomanagement, die für die Sicherheit von Anwendungen und Daten verantwortlich sind, kontinuierlich eine Software Bill of Materials (SBOM) für jede Anwendung erstellen. Diese bietet einen vollständigen Einblick in die jeweiligen Komponenten.“ – Gartner, 2019

Das Problem ist letztlich, dass die für die Pflege von Open-Source-Software zuständigen Personen zwar eine Sicherheitslücke schnell und „einfach“ beheben können, die enorme Verteilung von Software-Komponenten über Cloud-Dienste, Anwendungen und Infrastruktur hinweg es allerdings extrem schwierig macht, Updates schnell genug bereitzustellen. Darüber hinaus wissen sie möglicherweise gar nicht, dass ihre Software diese Komponente überhaupt enthält. Und wenn sie das nicht wissen, wie können sie dann mögliche Probleme beheben?

– VENTUREBEAT

Was ist eine Software Bill of Materials?

Eine Bill of Materials (BOM) erfasst Komponenten, Teile und Rohstoffe, die in Produkten wie Autos, Elektronik und Lebensmitteln enthalten sind. Die BOMs dienen im Grunde als Roadmap für die Produktion und beschreiben jeden Schritt in der gesamten Supply Chain.

Mit BOMs können Unternehmen Produktionsprobleme schnell identifizieren und beheben. Als beispielsweise 2016 festgestellt wurde, dass eine Reihe von Takata-Airbags defekt waren, konnten die Autohersteller mithilfe der in der BOM enthaltenen Teiledaten alle betroffenen Fahrzeuge ermitteln. Mit diesen Informationen konnten Hersteller schnell eine Liste der betroffenen Teile anzeigen und die entsprechenden Produkte zurückzurufen.

BOMs verbessern die Sicherheit und Leistung und beschleunigen die Lösung von Problemen.

Kurz gesagt, BOMs verbessern die Sicherheit und Leistung und beschleunigen die Lösung von Problemen. Und all diese Facetten sind auf die Software-Entwicklung übertragbar.

Die Anwendung von BOMs in der Software-Entwicklung

Wie wir bereits besprochen haben, enthält der Großteil moderner Software eine komplexe Reihe von sowohl proprietären als auch Open Source Komponenten. Bei der Arbeit mit komplizierten Komponenten ist es entscheidend, eine Liste aller Elemente und deren Herkunft zu erstellen. Ansonsten wird es deutlich schwieriger, die von Ihnen verwendeten Komponenten zu überwachen. Das kann zu veraltetem oder unsicherem Code führen.

Eine Software Bill of Materials (SBOM) ist eine Liste von Komponenten, aus denen sich eine Software-Anwendung zusammensetzt. Zu den wichtigsten Informationen gehören Komponentennamen, Lizenzinformationen, Versionsnummern und Anbieter. Dies reduziert das Risiko sowohl für den Hersteller als auch für den Verbraucher, denn so erhält man eine formelle Liste aller Details. Damit können andere Personen dann verstehen, was in ihrer Software enthalten ist, und entsprechend weiter verfahren.

Teil-4-weiterführende-Lektüre

 

Eine SBOM kann zwar keine unentdeckten Schwachstellen verhindern, aber damit lassen sich Probleme früher im Prozess erkennen und die Wahrscheinlichkeit reduzieren, dass sie am Ende in Ihrer Software landen. Da eine Supply Chain nur so stark ist wie ihr schwächstes Glied, können unsichtbare Software-Schwachstellen zu kostspieligen Sicherheitsverstößen führen.

Teil-4-6

Finden SBOMs Verbreitung? 

Viele Unternehmen haben immer noch kein vollständiges Bild davon, was in ihrer Software enthalten ist, und einige schauen nicht einmal nach. 2020 erstellten weniger als 50 % der Unternehmen SBOMs als Standardpraxis in der Software-Entwicklung. 

Doch das ändert sich zunehmend mit den gestiegenen Anforderungen bei der Software-Beschaffung. Immer mehr Unternehmen fragen entweder eine SBOM an oder schreiben diese vor, wenn sie Software kaufen und integrieren. Garner Research sagt dazu:

Bis 2025 werden 60 % der Unternehmen, die kritische Infrastruktur-Software erstellen oder beschaffen, SBOMs in ihrer Software-Entwicklung vorschreiben und standardisieren, gegenüber weniger als 20 % im Jahr 2022. Bis 2024 werden 90 % der Tools für die Software Composition Analysis die Möglichkeit bieten, SBOMs zu erstellen, um die sichere Nutzung von Open-Source-Software zu unterstützen. 2022 betrug dieser Wert von 30 %.“

– GARTNER RESEARCH, WIE VON SECURITY BOULEVARD BERICHTET

Vor allem die Erstellung und Pflege einer SBOM wird zu einer Voraussetzung für Verkäufe an die US-Bundesregierung. Im Mai 2021 erteilte Präsident Joe Biden eine Executive Order zur Verbesserung der Cybersicherheitslage in den USA. Mit der Verfügung werden das Commerce Department und die National Telecommunications and Information Administration (NTIA) damit beauftragt, die Mindestanforderungen an die SBOM zu veröffentlichen, um die Software Supply Chain zu sichern.

Ohne SBOM sind Unternehmen blind für bekannte anfällige Open-Source-Komponenten, die in ihren Software-Anwendungen integriert sind. 

Darüber hinaus werden dieselben Unternehmen ohne eine SBOM garantiert Schwierigkeiten haben, auf neue Zero-Day-Schwachstellen in Open-Source-Komponenten zu reagieren – wie beispielsweise Equifax 2017. Und Tausende von Unternehmen haben immer noch Probleme mit den jüngsten Log4j und Spring4Shell-Sicherheitslücken. Über 10.000 Schwachstellen, die jedes Jahr gemeldet werden, sind 10.000 gute Gründe, eine SBOM für alle Ihre Produktionsanwendungen zu pflegen.

Über 10.000 Schwachstellen, die jedes Jahr gemeldet werden, sind 10.000 gute Gründe, eine SBOM für alle Ihre Produktionsanwendungen zu pflegen.

Regelmäßige Software Composition Analysis

Entwicklungs- und Sicherheitsteams benötigen Geschwindigkeit, Genauigkeit und Präzision. Je schneller und präziser Sie alle Open-Source-Komponenten in einer Anwendung identifizieren können, desto eher können Sie falsch-positive und falsch-negative Ergebnisse, die bei anderen Methoden üblich sind, vermeiden und eine ausgereifte Software Composition Analysis-Lösung in der DevOps-Umgebung realisieren. Bestimmte Teile der SCA können zwar bei den anderen Schritten im Software Supply Chain Management helfen, allerdings haben wir uns entschieden, in diesem Abschnitt vor allem die Transparenz näher zu erläutern und in diesem Thema alles zusammenzufassen.

Teil-4-7

Bei der SCA geht es darum, alle Komponenten in einem Projekt zu untersuchen und das potenzielle Risiko (hauptsächlich Sicherheitsrisiko) dieser Komponenten zu ermitteln. Solche Analysen werden mithilfe von Tools durchgeführt, um Risiken in Ihren Anwendungen zu finden und zu identifizieren. Diese Tools können automatisiert werden und überwachen Komponenten über den gesamten Software Development Lifecycle (SDLC).


Automatisierte Malware-Erkennung und Reaktion auf anfällige Komponenten

Je später eine Sicherheitslücke gefunden wird, desto mehr Zeit und Mühe wird zur Behebung benötigt. Alle Komponenten in Ihrer Software können zu jedem Zeitpunkt von einer Schwachstelle betroffen sein, die entdeckt wird. Indem man so früh wie möglich im Prozess präzise Schwachstellendaten verwendet, kann man die eigene Software Supply Chain besser kontrollieren. Weniger falsch-positive und falsch-negative Ergebnisse sind das beste Maß für Genauigkeit und Vollständigkeit.

  • Ein falsch-positives Ergebnis bezeichnet eine bekannte Sicherheitslücke, die einer Komponente zugewiesen ist, die diese Sicherheitslücke nicht hat. In der Open-Source-Sicherheit tritt dies am häufigsten auf, wenn der Anbieter Komponenten schlecht abgleicht und ein sicheres Paket fälschlicherweise als ähnliche Komponente (mit Schwachstelle) identifiziert. Möglicherweise wird auch inkorrekt identifiziert, welche Versionen einer Komponente die Sicherheitslücke aufweisen.
  • Ein falsch-negatives oder „verpasstes positives“ Ergebnis ist ein viel schwerwiegenderer Analysefehler. Hierbei wird eine bekannte Schwachstelle in der eigenen Umgebung nicht gefunden, die zu ernsthaften Schäden führen kann. Das ist ein häufiges Problem bei transitiven Schwachstellen, die tief in den Software-Komponenten vergraben sind. Die Angst vor einem falsch-negativen Ergebnis kann dazu führen, dass einige weniger ausgereifte SCA-Lösungen Ihren Posteingang überlasten (siehe "verrauschte Sicherheitstools").

Teil-4-8

Andere Überlegungen zur SCA

Die meisten Test- und Analysetools haben die schwierige Aufgabe, zur richtigen Zeit die richtigen Informationen zu liefern. Und das gilt für SCA-Software umso mehr. Bei der Skalierung müssen Teams sich von der Mehr-ist-Besser-Denkweise lösen.

  • Verrauschte Sicherheitstools – Genauso wie Sie auf Ihrem neuen Smartphone oder Computer zu viele Benachrichtigungen erhalten, dass ein Programm spezielle Zugriffsrechte benötigt, können auch Entwicklungstools zu oft den Alarm auslösen. SCA-Tools, die ihre Ergebnisse nicht aussortieren, übergeben am Ende die Aufgabe, die Sicherheit zu gewährleisten, zurück an den Prüfer, da die Entwickler sich dann durch eine lange Liste möglicher Probleme wühlen müssen.

    Wenn Probleme, die entweder bereits behoben wurden oder eine niedrige Priorität haben, zu oft gemeldet werden, werden dadurch wirklich wichtige Meldungen ignoriert, oder die Produktivität wird beeinträchtigt.

  • Doppelte Sicherheitslücken – es ist möglich, mehrere anfällige Software-Pakete zu haben, von denen jedes mehrere Sicherheitslücken enthält. Häufig erhält man jedoch nur eine Meldung für die gesamte Familie von Problemen. 

    Zum Beispiel sind 10 Benachrichtigungen über verschiedene Log4j-Instanzen und -Versionen in Ihrer Umgebung zu viel, wenn Ihre Teams bereits alle Versionen aktualisiert haben. Sie benötigen nur eine einzige Meldung, und diese sollte wieder verschwinden, nachdem das Update installiert wurde (und Ihr SCA-Tool es überprüft hat).

  • Angepasste Benachrichtigungen – Sowohl Sicherheits- als auch Entwicklungs-Leads sollten in der Lage sein, Richtlinien darüber festzulegen, welche Arten von Software innerhalb des Software Development Lifecycle zulässig sind.
Sonatype Envelope

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