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.
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.
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.
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.
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.
Die neueste Version (5.3.x) von Spring-Core erscheint etwa alle 4 Wochen.
Das Projekt wartet diese 2 Versionen aktiv. Die dunklere Schattierung bedeutet, dass die Mehrheit der Community diese Versionen verwendet.
Das Projekt unterstützt diese Versionen nicht mehr aktiv. Teams sollten von diesen redundanten Versionen zu neueren migrieren.
Nachzügler aktualisieren weiterhin auf ältere, nicht unterstützte und sogar gefährdete Versionen.
Ältere Versionen sind anfällig und selbst für nicht anfällige ältere Versionen (4.3.15+) werden unweigerlich neue Schwachstellen offengelegt werden.
Die Community vermeidet im Allgemeinen .0- Releases und Pre-Releases.
Wählen Sie keine Versionen wie Alpha, Beta, Milestone oder Release Candidates.
.png?width=68&height=88&name=Vector%20(1).png)
Aktualisieren Sie nicht auf eine anfällige Version.
.png?width=71&height=46&name=Vector%20(2).png){kind=small}
Aktualisieren Sie auf einen niedrigeren Risikograd, falls Ihre aktuelle Version anfällig ist.
.png?width=83&height=61&name=Vector%20(3).png)
Wenn eine Komponente zweimal kurz hintereinander veröffentlicht wird, wählen Sie die spätere Version.
.png?width=71&height=96&name=Vector%20(4).png)
Wählen Sie einen Migrationspfad (von Version zu Version), den andere gewählt haben.
.png?width=69&height=82&name=Vector%20(5).png)
Wählen Sie eine Version, die fehlerhafte Änderungen am Code minimiert.
.png?width=79&height=74&name=Vector%20(6).png)
Wählen Sie eine Version, die von der Mehrheit der Verbraucher verwendet wird.
.png?width=80&height=80&name=Vector%20(7).png)
Wenn alles andere gleich ist, wählen Sie die neueste Version.
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.
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.
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.
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.
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.
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.
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.
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.
.png)
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“.
.png)
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.
