Sonatype präsentiert umfassendes Software Supply Chain Management | Pressemitteilung

2021

State of the Software Supply Chain

Zum siebten Jahr in Folge verbindet der '2021 State of the Software Supply Chain Report' ein breites Spektrum an öffentlichen mit proprietären Daten und offenbart auf diese Weise aussagekräftige Erkenntnisse über Open-Source-Ansätze und deren zunehmend bedeutende Rolle im Hinblick auf die digitale Innovation.

banner-right

1

Open-Source-Angebot, -Nachfrage und -Sicherheit

Das Open-Source-Angebot wächst exponentiell.

Derzeit enthalten die vier führenden Open-Source-Ökosysteme insgesamt 37.451.682 Komponenten und Pakete. Dieselben Communitys haben im vergangenen Jahr insgesamt 6.302.733 neue Versionen von Komponenten/Paketen veröffentlicht und 723.570 brandneue Projekte zur Unterstützung von 27 Millionen Entwicklern weltweit eingeführt.

Verfügbares Angebot an Open Source

Java

0 1 Mio. 2 Mio. 3 Mio. 4 Mio. 5 Mio. 6 Mio. 7 Mio. 8 Mio. Versionen Projekte Neu in 2021 Vor 2021 verfügbar 430.995 7,3 MILLIONEN

Javascript

0 1 Mio. 2 Mio. 3 Mio. 4 Mio. 5 Mio. 6 Mio. 7 Mio. 8 Mio. Versionen Projekte Neu in 2021 Vor 2021 verfügbar 21 MILLIONEN 1,8 MILLIONEN

Python

0 1 Mio. 2 Mio. 3 Mio. 4 Mio. 5 Mio. 6 Mio. 7 Mio. 8 Mio. Versionen Projekte Neu in 2021 Vor 2021 verfügbar 3 MILLIONEN 336.402

.Net

0 1 Mio. 2 Mio. 3 Mio. 4 Mio. 5 Mio. 6 Mio. 7 Mio. 8 Mio. Versionen Projekte Neu in 2021 Vor 2021 verfügbar 5,6 MILLIONEN 338.423
Die Open-Source-Nachfrage steigt weiterhin explosionsartig an.
Zunahme der Downloads
im Vergleich zum Vorjahr 2020–2021
0 % 10 % 20 % 30 % 40 % 50 % 60 % 70 % 80 % 90 % 100 % .NET Python JavaScript Java 71 % Anstieg 267 AUF 457 MILLIARDEN 50 % Anstieg 1 AUF 1,5 BILLIONEN 78 % Anstieg 44 AUF 78 MILLIARDEN Anstieg im Vergleich zum Vorjahr Prozentsatz 92 % Anstieg 66 AUF 127 MILLIARDEN
Die Open-Source-Nachfrage steigt weiterhin explosionsartig an.

Im Jahr 2021 wird weltweit mit mehr als 2,2 Billionen Anfragen für Open-Source-Software-Pakete gerechnet, was im Vergleich zum Vorjahr einem 73%igen Anstieg der Downloads von Open-Source-Komponenten durch Entwickler entspricht. Trotz des wachsenden Download-Volumens ist der Prozentsatz der verfügbaren Komponenten, die in Produktionsanwendungen verwendet werden, schockierend gering.

Schwachstellen sind in beliebten Projekten häufiger anzutreffen.

Bei den beliebtesten 10 % der OSS-Projektversionen beträgt die Wahrscheinlichkeit, dass sie bekannte Schwachstellen enthalten, im Durchschnitt 29 %. Umgekehrt beträgt die Wahrscheinlichkeit, dass die restlichen 90 % der Projektversionen bekannte Schwachstellen enthalten, nur 6,5 %. Zusammengenommen deuten diese Statistiken darauf hin, dass sich die überwiegende Mehrheit der Sicherheitsforschung (White Hat und Black Hat) auf das Auffinden und Beheben (oder Ausnutzen) von Schwachstellen in Projekten konzentriert, die häufiger genutzt werden.

Dichte der Schwachstellen des Releases vs. Beliebtheit

Java (Maven)

0,00 0,25 0,50 0,75 1,00 1,25 1,50 1,75 2,00 2,25 2,50 Anfällig Nicht anfällig Prozent der anfälligen Versionen nach Beliebtheitsgruppe x % Beliebtheit Obere 10 % Untere 10 % 7 % 7 % 3 % 4 % 6 % 2 % 3 % 6 % 3 % 26 %

JavaScript (npm)

0,00 0,25 0,50 0,75 1,00 1,25 1,50 1,75 2,00 2,25 2,50 Anfällig Nicht anfällig Beliebtheit Obere 10 % Untere 10 % 39 % 17 % 9 % 8 % 6 % 6 % 7 % 7 % 7 % 4 %

Python (pypi)

0,00 0,25 0,50 0,75 1,00 1,25 1,50 1,75 2,00 2,25 2,50 Anfällig Nicht anfällig Beliebtheit Obere 10 % Untere 10 % 38 % 14 % 12 % 3 % 6 % 5 % 11 % 9 % 7 % 5 %

.NET (Nuget)

Anfällig Nicht anfällig 0,00 0,25 0,50 0,75 1,00 1,25 1,50 1,75 2,00 2,25 2,50 Beliebtheit Obere 10 % Untere 10 % 16 % 6 % 6 % 6 % 6 % 6 % 8 % 7 % 5 % 4 %
Statistik zur Software Supply Chain 2021
Ökosystem
Gesamtanzahl
der Projekte
Gesamtanzahl
der Projektversionen
Download-
Anfragen
Anstieg
der Downloads im Vergleich zum Vorjahr
Ökosystem-
Projektnutzung
Schwachstellen-dichte bei verwendeten Versionen:
10 % der beliebtesten
Schwachstellen-dichte bei verwendeten Versionen:
90 % der am wenigsten
beliebten
Java
JavaScript
Python
.Net
Gesamt/Durchschnitt
431K
1.9M
336K
338K
3M
7.3M
21M
3M
5.6M
37M
457B
1.5T
127B
78B
2.2T
71%
50%
92%
78%
73%
15%
2%
4%
2%
6%
23%
39%
38%
15%
29%
4%
8%
8%
6%
6.5%
Prominente Angriffe auf die Software Supply Chain
Dez. 2020–Juli 2021
Dezember 2020
SolarWinds

Kriminelle Akteure verschafften sich Zugang zur Dev-Infrastruktur von SolarWinds und schleusten Schadcodes in Update-Binärdateien der Orion-Plattform ein. 18.000 Kunden luden von Trojanern befallene Updates automatisch herunter, die Backdoors in ihre Systeme einschleusten und es kriminellen Akteuren ermöglichten, private Netzwerke nach Belieben anzugreifen.

Februar 2021
Namespace Confusion

Drei Tage, nachdem bekannt wurde, dass ein Sicherheitsforscher unter Anwendung eines neuartigen Supply-Chain-Angriffs auf die Netzwerke von mehr als 35 Technologieunternehmen zugegriffen hatte, wurden mehr als 300 schädliche Nachahmungsangriffe (Copycats) registriert. Innerhalb eines Monats hatten mehr als 10.000 Namespace Confusion Copycats npm und weitere Ökosysteme infiltriert.

April 2021
Codecov

Ein Angreifer konnte über einen Fehler von Codecov in Bezug auf die Erstellung von Docker-Images auf Anmeldedaten zugreifen. Mit diesen Anmeldedaten konnte im Zuge des Angriffs anschließend das Bash-Uploader-Script von Codecov geändert werden, das entweder direkt von Kunden oder über die anderen Uploader von Codecov, beispielsweise Github Action, genutzt wurde. Mithilfe dieses geänderten Scripts erbeutete der Angreifer Anmeldedaten aus der CI-Umgebung von Kunden, die dieses verwendeten.

Mai 2021
Microsoft's WinGet

Am Wochenende nach dem Launch wurde die Software-Registry von Winget mit Pull-Requests für Apps überhäuft, die entweder Duplikate oder fehlerhaft waren. Einige neu hinzugefügte doppelte Pakete waren beschädigt und überschrieben die vorhandenen Pakete, was zu ernsthaften Bedenken bezüglich der Integrität des Winget-Ökosystems führte.

Juli 2021
Kaseya

Eine Ransomware-Gruppe entdeckte eine Zero-Day-Schwachstelle in einer Software-Plattform für Fernüberwachung und -verwaltung, die von Dutzenden von Managed Security Providern (MSP) verwendet wird, und nutzte diese aus. Da diese MSPs Tausende nachgelagerte Kunden bedienen, konnten die Hacker einen Ransomware-Angriff ausführen, der 1.500 Opfer betraf.

Software-Supply-Chain-Angriffe steigen um 650 %

Die Mitglieder der weltweiten Open-Source-Community haben es mit einer neuartigen, sich rasant ausbreitenden Bedrohung zu tun, bei der aggressive Angreifer absichtlich Open-Source-Projekte manipulieren, um die kommerzielle Software Supply Chain zu infiltrieren – und nicht mit passiven Akteuren, die quasi beiläufig bekannte Schwachstellen ausnutzen.

Von Februar 2015 bis Juni 2019 wurden 216 Angriffe auf Software Supply Chains registriert. Von Juli 2019 bis Mai 2020, stieg die Anzahl der Angriffe auf 929. Im vergangenen Jahr wurden jedoch mehr als 12.000 solcher Angriffe gezählt, was einem Anstieg von 650 % im Vergleich zum Vorjahr entspricht.

Next-Generation Software Supply Chain-Angriffe (2015–2020)

Dependency Confusion, Typosquatting und Implementierung von Schadcode

2020 2019 2018 2017 2015 2021 0 2.000 4.000 6.000 8.000 10.000 12.000 650 % ANSTIEG IM VERGLEICH ZUM VORJAHR
Prominente Angriffe auf die Software Supply Chain
Dez. 2020–Juli 2021
Dezember 2020
SolarWinds

Kriminelle Akteure verschafften sich Zugang zur Dev-Infrastruktur von SolarWinds und schleusten Schadcodes in Update-Binärdateien der Orion-Plattform ein. 18.000 Kunden luden von Trojanern befallene Updates automatisch herunter, die Backdoors in ihre Systeme einschleusten und es kriminellen Akteuren ermöglichten, private Netzwerke nach Belieben anzugreifen.

Februar 2021
Namespace Confusion

Drei Tage, nachdem bekannt wurde, dass ein Sicherheitsforscher unter Anwendung eines neuartigen Supply-Chain-Angriffs auf die Netzwerke von mehr als 35 Technologieunternehmen zugegriffen hatte, wurden mehr als 300 schädliche Nachahmungsangriffe (Copycats) registriert. Innerhalb eines Monats hatten mehr als 10.000 Namespace Confusion Copycats npm und weitere Ökosysteme infiltriert.

April 2021
Codecov

Ein Angreifer konnte über einen Fehler von Codecov in Bezug auf die Erstellung von Docker-Images auf Anmeldedaten zugreifen. Mit diesen Anmeldedaten konnte im Zuge des Angriffs anschließend das Bash-Uploader-Script von Codecov geändert werden, das entweder direkt von Kunden oder über die anderen Uploader von Codecov, beispielsweise Github Action, genutzt wurde. Mithilfe dieses geänderten Scripts erbeutete der Angreifer Anmeldedaten aus der CI-Umgebung von Kunden, die dieses verwendeten.

Mai 2021
Microsoft's WinGet

Am Wochenende nach dem Launch wurde die Software-Registry von Winget mit Pull-Requests für Apps überhäuft, die entweder Duplikate oder fehlerhaft waren. Einige neu hinzugefügte doppelte Pakete waren beschädigt und überschrieben die vorhandenen Pakete, was zu ernsthaften Bedenken bezüglich der Integrität des Winget-Ökosystems führte.

Juli 2021
Kaseya

Eine Ransomware-Gruppe entdeckte eine Zero-Day-Schwachstelle in einer Software-Plattform für Fernüberwachung und -verwaltung, die von Dutzenden von Managed Security Providern (MSP) verwendet wird, und nutzte diese aus. Da diese MSPs Tausende nachgelagerte Kunden bedienen, konnten die Hacker einen Ransomware-Angriff ausführen, der 1.500 Opfer betraf.

Praktische Empfehlung

Um das Tempo der digitalen Innovation ohne Qualitäts- und Sicherheitseinbußen zu beschleunigen, sollten Führungskräfte im Bereich Entwicklung und Risikomanagement Angebot, Nachfrage und Risikodynamik im Zusammenhang mit Open-Source-Ökosystemen von Drittanbietern verstehen. Zudem sollten sie Open-Source-Richtlinien sorgfältig definieren und in der gesamten Software Supply Chain automatisch durchsetzen.

2

Einsicht in vorbildliche Open-Source-Projekte

Manche Open-Source-Projekte sind definitiv besser als andere. Aber woran erkennt man sie? Dieses Jahr haben wir drei verschiedene Methoden zur Identifizierung vorbildlicher Open-Source-Projekte untersucht: Sonatype Mean Time to Update (durchschnittliche Dauer bis zur Aktualisierung, MTTU), OpenSSF Criticality und Libraries.IO Sourcerank. Wir haben festgestellt, dass insbesondere die MTTU in Kombination mit OpenSSF Criticality mit vorbildlichen Projektergebnissen in den Bereichen Sicherheit und Entwicklungsproduktivität in Zusammenhang steht.

Metriken für die Bewertung der relativen Qualität eines OSS-Projekts
  • Sonatype MTTU
  • OpenSSF Criticality
  • Libraries.io Sourcerank

Sonatype MTTU liefert ein Maß für die Projektqualität basierend auf der Geschwindigkeit der Aktualisierung von Abhängigkeiten im Projekt. Ein niedriger MTTU-Wert bedeutet schnellere Aktualisierung und ist somit besser. Komponenten, die durchwegs schnell auf Aktualisierungen von Abhängigkeiten reagieren, haben eine geringere MTTU. Komponenten, die langsam reagieren oder hinsichtlich ihrer Aktualisierungszeiten hohe Schwankungen aufweisen, haben eine höhere MTTU.

OpenSSF Criticality erfasst die Community, Nutzung und Aktivität eines Projekts. Daraus wird eine Bewertungsnote errechnet, mit der gemessen werden soll, wie wichtig das Projekt für das Open-Source-Ökosystem ist.

Libraries.io Sourcerank zielt darauf ab, die Qualität der Software zu messen, wobei der Schwerpunkt vor allem auf der Projektdokumentation, der Maturität und der Community liegt. Die Berechnung erfolgt durch die Auswertung einer Reihe von Ja/Nein-Antworten wie „Ist das Projekt älter als sechs Monate?“ und einer Reihe numerischer Fragen wie „Wie viele ‚Sterne‘ hat das Projekt?“. Diese werden zu einer einzigen Bewertungsnote zusammengefasst, wobei für die Ja/Nein-Fragen eine festgelegte Anzahl von „Punkten“ addiert oder abgezogen wird und die numerischen Fragen mithilfe einer Formel in Punkte umgewandelt werden, z. B. „log(num_stars)/2.“ Die aktuelle Höchstpunktzahl beträgt ca. 30.

Eine geringere MTTU ist besser.

Komponenten, die durchwegs schnell auf Aktualisierungen von Abhängigkeiten reagieren, haben eine geringe MTTU. Komponenten, die entweder durchwegs langsam reagieren oder hinsichtlich ihrer Aktualisierungszeit hohe Schwankungen aufweisen, haben eine höhere MTTU.

Angenommen, wir haben eine Komponente A mit Abhängigkeiten B und C, beide mit Version 1.2. Nehmen wir weiterhin an, für B und C erscheint jeweils eine neue Version (1.3), und einige Zeit später veröffentlicht A eine neue Version, die die Version von B und C auf 1.3 erhöht. Die Zeit zwischen der Veröffentlichung von Version 1.3 für B und der Veröffentlichung von Version 1.3 für A ist die Zeit bis zum Upgrade (Time to Upgrade, TTU) für die Migration von A auf Version 1.3 für B (und entsprechend auch für die Einführung von Version 1.3 für C durch A). Der Durchschnitt all dieser Upgrade-Zeiten wird als MTTU bezeichnet.

Erweitern für zusätzliche Informationen.
MTTU-update-2
Aggregierte MTTUs verbessern sich im Laufe der Zeit.

Nicht nur die Zahl der Projekte ist im Laufe der Jahre gestiegen, sondern es ist auch ein klarer Trend zu schnelleren MTTUs zu beobachten. Die durchschnittliche MTTU für alle Projekte im Jahr 2011 betrug 371 Tage. Im Jahr 2014 waren es 302 Tage und im Jahr 2018 158 Tage. Im Jahr 2021, mit Stand 1. August, betrug die durchschnittliche MTTU 28 Tage – und fiel damit um mehr als die Hälfte geringer aus als im Jahr 2020, als ein durchschnittliches Projekt 73 Tage in Anspruch nahm.

Dichte MTTU in Tagen 10 –2 10 –1 10 0 10 1 10 2 10 3 10 4 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 (prognostiziert) 2021 2020 2019 2017 2016 2018 2015 2014 2013 2012 2011 0.00 0.02 0.04 0.06 0.08 0.10 0.12 0.14
Die MTTU korreliert stark mit der MTTR.
MTTU_MTTRchart

Angenommen, ein Projekt A enthält eine Abhängigkeit B und B weist eine Schwachstelle auf, die zum Datum D1 bekannt wurde. Dann aktualisiert A die Version von B, die es verwendet, zum Datum D2. Die Dauer bis zur Behebung (Time to Remediate, TTR) bezeichnet die Zeit zwischen D1 und D2, gemessen in Tagen, und die MTTR bezieht sich auf die durchschnittliche TTR für ein Projekt in Bezug auf alle bekannten Sicherheitsschwachstellen.

Erweitern für zusätzliche Informationen.
Die MTTU korreliert stark mit der MTTR.

MTTU misst zwar nicht direkt die Geschwindigkeit, mit der Projekte öffentlich gemeldete Schwachstellen beheben, steht jedoch trotzdem in Korrelation mit der mittleren Zeit bis zur Behebung (Mean Time To Remediate, MTTR) eines Projektes, d. h. der Zeit, die für die Aktualisierung von Abhängigkeiten mit öffentlich bekannten Schwachstellen erforderlich ist. Somit betrachten wir die MTTU als die beste verfügbare Metrik, um die Auswirkung einer Komponente auf die Sicherheit von Projekten zu bestimmen, die diese Komponente enthalten.

Praktische Empfehlungen

Anbieter, die Enterprise-Software entwickeln, sollten die Auswahl qualitativ hochwertiger Open-Source-Projekte als eine wichtige strategische Entscheidung betrachten.

Um redundante Abhängigkeiten zu vermeiden und Sicherheitsrisiken im Zusammenhang mit Open Source von Drittanbietern zu minimieren, sollten Software-Entwicklungsteams aktiv auf Projekte setzen, die durchweg niedrige MTTU-Werte (durchschnittliche Dauer bis zur Aktualisierung) und hohe OpenSSF-Criticality-Werte aufweisen.

3

Wie verwalten andere Unternehmen Open-Source-Abhängigkeiten?

Für den diesjährigen Bericht haben wir 4 Millionen Entscheidungen zum Abhängigkeitsmanagement aus der Praxis untersucht, die sich über 100.000 Anwendungen erstrecken. Die nachstehend aufgeführten Erkenntnisse sind aufschlussreich.

Trotz des wachsenden Download-Volumens ist der Prozentsatz der verfügbaren Komponenten, die in Produktionsanwendungen zu beobachten sind, schockierend gering.

Im Durchschnitt kommen in Java-Anwendungen in Produktionsunternehmen 10 % aller verfügbaren Open-Source-Komponenten zur Anwendung und kommerzielle Entwicklungsteams aktualisieren nur 25 % dieser genutzten Komponenten aktiv.

Aktive Projekte im Maven Central Repository
430.000 Projekte in Maven Projekte in 100.000 Anwendungen 40.000 über 100.000 Anwendungen hinweg Projekte wurden im letzten Jahr aktiv aktualisiert 10.000
69 % der Entscheidungen zum Abhängigkeitsmanagement sind suboptimal.
5 Gruppen von Migrationsentscheidungen
Optimale Entscheidung Optimale Version ausgewählt 31 % Nicht perfekte Entscheidungen Subjektiv suboptimale Version ausgewählt 64 % Gefährliche Entscheidungen Nicht-subjektiv suboptimale Version ausgewählt 3 % Riskante Entscheidungen Version vor der Veröffentlichung ausgewählt 1 % Sackgassen-Entscheidungen Keine gute Option verfügbar 1 %
69 % der Entscheidungen zum Abhängigkeitsmanagement sind suboptimal.

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. Hinzu kommt, dass einige hyperaktive Projekte mehr als 8.000 Mal pro Jahr neue Versionen veröffentlichen. Somit stehen Entwickler ständig vor der Entscheidung, wann Abhängigkeiten von Drittanbietern innerhalb ihrer Anwendungen aktualisiert werden sollten (und wann nicht). Angesichts dieser Umstände haben sich die Forscher von Sonatype die Frage gestellt: Treffen Entwickler effiziente Entscheidungen beim Abhängigkeitsmanagement? Wir haben 100.000 Anwendungen untersucht und mehr als 4.000.000 Komponentenmigrationen (Upgrades) analysiert und festgestellt, dass 69 % dieser Entscheidungen suboptimal waren.

Trotz der unstrukturierten Entscheidungsfindung gibt es Anzeichen für „Schwarmwissen“.

Das folgende Diagramm bietet einen visuellen Überblick über das allgemeine Migrationsverhalten im vergangenen Jahr im Zusammenhang mit Spring-Core, einer einzelnen Komponente innerhalb des beliebten Spring-Frameworks. Die Y-Achse zeigt die Upgrade-Aktivitäten der letzten 52 Wochen, wobei die obere Zeile die vor einem Jahr getroffenen Migrationsentscheidungen und die untere Zeile die in der letzten Woche getroffenen Migrationsentscheidungen darstellt. Die X-Achse zeigt die 150 aktuellsten Versionen. Dabei befinden sich die älteren Versionen links, die neueren Versionen hingegen rechts. Klicken Sie auf die Punkte unten, um die wichtigsten Erkenntnisse zu sehen.

Migrationsverhalten bei org.springframework:spring-core9. August 2020–1. August 2021
1

Die neueste Version (5.3.x) von Spring-Core erscheint etwa alle 4 Wochen.

2

Das Projekt wartet diese 2 Versionen aktiv. Die dunklere Schattierung bedeutet, dass die Mehrheit der Community diese Versionen verwendet.

3

Das Projekt unterstützt diese Versionen nicht mehr aktiv. Teams sollten von diesen redundanten Versionen zu neueren migrieren.

4

Nachzügler aktualisieren weiterhin auf ältere, nicht unterstützte und sogar gefährdete Versionen.

5

Ältere Versionen sind anfällig und selbst für nicht anfällige ältere Versionen (4.3.15+) werden unweigerlich neue Schwachstellen offengelegt werden.

6

Die Community vermeidet im Allgemeinen .0- Releases und Pre-Releases.

8 Regeln für das Upgrade auf die optimale Version
Objektiv schlechte Entscheidungen vermeiden
Vector

Wählen Sie keine Versionen wie Alpha, Beta, Milestone oder Release Candidates.

Vector (1)

Aktualisieren Sie nicht auf eine anfällige Version.

Vector (2)

Aktualisieren Sie auf einen niedrigeren Risikograd, falls Ihre aktuelle Version anfällig ist.

Vector (3)

Wenn eine Komponente zweimal kurz hintereinander veröffentlicht wird, wählen Sie die spätere Version.

Subjektiv schlechte Entscheidungen vermeiden
Vector (4)

Wählen Sie einen Migrationspfad (von Version zu Version), den andere gewählt haben.

Vector (5)

Wählen Sie eine Version, die fehlerhafte Änderungen am Code minimiert.

Vector (6)

Wählen Sie eine Version, die von der Mehrheit der Verbraucher verwendet wird.

Vector (7)

Wenn alles andere gleich ist, wählen Sie die neueste Version.

Wenn Sie diese Regeln einhalten, führt dies zu optimalen Aktualisierungen.
Sparen Sie Zeit und Geld.

Intelligente Automatisierung, bei der seitens der Entwicklungsteams eine Standardisierung hin zu vorbildlichen Open-Source-Projekten erfolgt, könnte in unserer Stichprobe von 100.000 Produktionsanwendungen in der Praxis 1,6 Millionen Stunden und 240 Millionen US-Dollar einsparen und somit Kosten- und Zeiteinbußen vermeiden. Auf die gesamte Software-Industrie hochgerechnet würden die damit verbundenen Einsparungen in die Milliarden gehen.

Der Vorteil von intelligenter Automatisierung für Entwicklungsteams
Strategien für ein optimales Abhängigkeitsmanagement: So viel Aktualität wie möglich, jedoch mit einem gewissen Grad an Zurückhaltung

Brandaktuell heißt auch gefährlich. So viel Aktualität wie möglich herzustellen, jedoch mit einem gewissen Grad an Zurückhaltung, ist die beste Strategie. Bei der Analyse des allgemeinen Migrationsverhaltens in Bezug auf Verfahren zum Abhängigkeits-Management konnten wir drei unterschiedliche Muster des Teamverhaltens beobachten: Teams, in denen Chaos herrscht, Teams, die immer brandaktuelle Versionen nutzen und Teams, die auf so viel Aktualität wie möglich setzen, jedoch einen gewissen Grad an Zurückhaltung mitbringen.

Strategien für das Abhängigkeitsmanagement
Teams, in denen Chaos herrscht

Den Entwicklern, die in diesen Teams arbeiten, fehlt eine automatisierte Orientierungshilfe. Sie aktualisieren Abhängigkeiten nur selten. Wenn sie doch Abhängigkeiten aktualisieren, nutzen sie ihr Bauchgefühl und treffen häufig suboptimale Entscheidungen. Dieser Ansatz für das Abhängigkeitsmanagement ist hochgradig reaktiv, nicht skalierbar und führt zu redundanter Software und einem erhöhten Sicherheitsrisiko.

MEHR LESEN WENIGER ANZEIGEN
Teams, die sowohl auf Aktualität als auch Zurückhaltung setzen

Entwickler, die in diesen Teams arbeiten, profitieren von einer intelligenten und kontextbezogenen Automatisierung. Die Aktualisierung von Abhängigkeiten wird automatisch empfohlen, aber nur, wenn sie optimal ist. Diese Art von intelligenter Automatisierung hält die Software auf dem neuesten Stand, ohne dass versehentlich unnötiger Aufwand oder ein erhöhtes Sicherheitsrisiko entsteht. Dieser Ansatz ist proaktiv, skalierbar und hinsichtlich der Kosteneffizienz und der Qualität der Ergebnisse optimal.

MEHR LESEN WENIGER ANZEIGEN
Teams, die auf brandaktuelle Versionen setzen

Entwickler, die in diesen Teams arbeiten, profitieren von einer simplen, aber nicht kontextbezogenen Automatisierung. Abhängigkeiten werden automatisch auf die neueste Version aktualisiert, unabhängig davon, ob diese optimal ist oder nicht. Solch eine Automatisierung hilft dabei, die Software auf dem neuesten Stand zu halten, kann aber versehentlich zu höheren Sicherheitsrisiken und erhöhten Kosten aufgrund von unnötigen Aktualisierungen und fehlerhaften Builds führen. Dieser Ansatz ist proaktiv und skalierbar, aber hinsichtlich der Kosten und Ergebnisse nicht optimal.

MEHR LESEN WENIGER ANZEIGEN
Praktische Empfehlungen

Software-Entwicklungsteams sollten sich bemühen, Entscheidungen zum Abhängigkeitsmanagement zu standardisieren.

Führungskräfte im Bereich der Entwicklung sollten dafür sorgen, dass Entwicklern möglichst viele Informationen zur Verfügung stehen. So können Kosten- und Zeiteinsparungen erzielt werden.

Entwicklungsleiter sollten Tools zur Automatisierung intelligenter Entscheidungen in Bezug auf das Abhängigkeitsmanagement einsetzen.

4

Umfrage zur Maturität der Software Supply Chain

Für den diesjährigen Bericht haben wir 702 Experten aus dem Entwicklungsbereich über Verfahren in Bezug auf das Management der Software Supply Chain befragt, etwa zu Ansätzen und Überzeugungen bei der Verwendung von Open-Source-Komponenten, zur organisatorischen Gestaltung, Governance, zum Genehmigungsprozess sowie zu Werkzeugen.

Diskrepanz zwischen Wahrnehmung und Realität in Bezug auf die Maturität der Software Supply Chain

Subjektiv geben die Umfrageteilnehmer an, dass sie gute Arbeit bei der Beseitigung fehlerhafter Komponenten leisten und dass ihnen bekannt ist, wo die Risiken in der Lieferkette liegen. Objektiv zeigt die Forschung, dass es Entwicklungsteams an strukturierter Anleitung mangelt und dass sie häufig suboptimale Entscheidungen in Bezug auf das Management der Software Supply Chain treffen.

Wir haben alle Umfrageantworten mit den fünf verschiedenen Maturitätsebenen der Software Supply Chain abgeglichen und festgestellt, dass die Mehrheit der Befragten weniger als die Ebene „Kontrolle“ erreicht haben – welche als der Punkt gilt, zu dem eine Organisation von einem bloßen Lernprozess zu einer minimalen Maturitätsebene übergeht, die Ergebnisse von hoher Qualität ermöglicht.

Über die Punkte rechts erhalten Sie weitere Informationen.

Maturität der Software Supply Chain nach Themenbereich
5., 50. und 95. Perzentil
1
Die Mehrheit der Befragten verfolgt einen „Ad-hoc“-Ansatz für das Management der Software Supply Chain.
2
Die einzigen beiden Themenbereiche, bei denen die Befragten eine hohe Maturitätsebene aufwiesen, waren Inventar und Mängelbeseitigung.
3
Vergleicht man die Antworten auf die Umfrage mit der durchgeführten objektiven Analyse, so zeigt sich eine Diskrepanz zwischen der Realität und den Vorstellungen der Befragten: 70 % der Maßnahmen zur Schwachstellenbehebung sind in Wirklichkeit suboptimal.
Praktische Empfehlung

Die Umfrage deutet darauf hin, dass die Befragten davon überzeugt sind, dass sie in Bereichen gute Leistungen erbringen, in denen dies in Wahrheit nicht der Fall ist. Das führt uns vor Augen, wie es wichtig ist, stets die tatsächliche Leistung des Unternehmens im Blick zu haben, anstatt auf Basis von Vermutungen zu arbeiten. Zudem ist es essenziell, die eigenen Workflows und Systeme fortlaufend mit den gewünschten Ergebnissen abzugleichen.

5

Einführung von Vorschriften und Standards für die Software Supply Chain

Nach mehreren Angriffen auf kritische Infrastrukturen im Jahr 2020 begannen Regierungen auf der ganzen Welt damit, Vorschriften und Standards zur Verbesserung der Sicherheit und des Bedrohungsschutzes für Software Supply Chains auszuarbeiten.

American Flag
Die Vereinigten Staaten von Amerika

Im Mai 2021 unterzeichnete Präsident Biden die Executive Order on Improving the Nation’s Cybersecurity, eine präsidiale Anordnung, die in einer Zeit, in der Cyberspionage und nationalstaatliche Angriffe auf kritische Infrastrukturen krisenhafte Ausmaße erreichen, als Meilenstein für die Regierung der USA gilt.

UK Flag
Das Vereinigte Königreich

Die britische Regierung kündigte an, Ratschläge in Bezug auf die Abwehr von Angriffen auf digitale Supply Chains von Organisationen, die IT-Dienste nutzen, oder MSPs, die Software und Dienste anbieten, in Anspruch zu nehmen.

Germany Flag
Deutschland

Deutschland verabschiedete das IT-Sicherheitsgesetz 2.0 als Aktualisierung des ersten Gesetzes, um „die Cyber- und Informationssicherheit vor dem Hintergrund der immer häufigeren und komplexeren Cyberangriffe und der fortschreitenden Digitalisierung des alltäglichen Lebens zu erhöhen“.

European Union Flag
Europäische Union

Die Agentur der Europäischen Union für Cybersicherheit (ENISA) hat im Juli 2021 einen Bericht mit dem Titel „Untersuchung der Zunahme von Angriffen auf die Sicherheit der Supply Chain“ veröffentlicht. Der Bericht geht auf 24 verschiedene Angriffe auf die Software-Supply-Chain ein und enthält Empfehlungen, die Unternehmen umsetzen sollten, um sich vor Angriffen zu schützen.

Praktische Empfehlung

Da Regierungen endlich die Risiken im Zusammenhang mit unkontrollierten Software-Supply-Chains erkennen, werden energisch Maßnahmen ergriffen, um die Software-Industrie an andere produzierende Branchen angleichen. Achten Sie darauf, was in Sachen Gesetzgebung auf Ihrem Markt passiert, beteiligen Sie sich an den öffentlichen Diskussionen und seien Sie darauf vorbereitet, Ihre Entwicklungsverfahren entsprechend zu ändern.

Tiefer einsteigen und vollständigen Bericht herunterladen

Entwickler treffen in jeder Phase des DevSecOps-Wertstroms eine Viehlzahl digitaler Entscheidungen, über die sie noch vor einem Jahr nicht nachdenken mussten. Ein Verständnis davon, wie sich diese Entscheidungen optimieren lassen und wie sie sich auf die Software-Supply-Chain insgesamt auswirken, spielt eine zentrale Rolle für den Erfolg eines Unternehmens.

Lesen Sie den vollständigen Bericht, um weitere Erkenntnisse, Analysen und Ratschläge rund um die Entwicklung optimaler Software-Supply-Chains zu erhalten.