Heutzutage ist es keine Überraschung, wenn die Sicherheit der Software-Lieferkette bedroht wird. Zunächst sorgte log4j für Schlagzeilen und veranlasste alle dazu, fieberhaft Maßnahmen gegen diese weitverbreitete und schwerwiegende Schwachstelle in der Software-Lieferkette zu ergreifen.
In jüngerer Zeit rückte Spring4Shell in unseren Fokus – eine weitere durch ein Framework verursachte Schwachstelle, die Unternehmen bei der Abwehr der Bedrohung vor große Herausforderungen stellt.
Daher war es durchaus erfreulich zu sehen, dass GitHub neue Funktionen einführt zur Verbesserung der Sicherheit der Software-Lieferkette. Besonders erfreulich war dies nach der Lektüre von Sonatypes aktuellem Bericht „State of the Software Supply Chain“, der Statistiken enthält, die jeden sicherheitsbewussten Technologieexperten unabhängig von seiner Rolle alarmieren sollten. Besonders hervorzuheben sind:
- Mittlerweile sind 37 Millionen Versionen von Open-Source-Komponenten verfügbar
- 29 % der beliebten Projekte enthalten mindestens eine bekannte Sicherheitslücke
- Anstieg der Cyberangriffe auf Open-Source-Anbieter um 650 % gegenüber dem Vorjahr
Diese Ergebnisse sind besonders besorgniserregend, da der Bericht zu dem Schluss kam, dass „eine moderne Anwendung im Durchschnitt 128 Open-Source-Abhängigkeiten enthält“.
Nun, Sie wissen ja, dass ich kein Fan vom Rechnen bin, aber rechnen wir trotzdem ein bisschen.
Im Bericht „State of Application Strategy 2022“ finden sich mehrere bemerkenswerte Statistiken:
- Moderne Anwendungen (container-nativ und mobil) machen durchschnittlich 33 % des Anwendungsportfolios eines Unternehmens aus
- Unternehmen aller Branchen verfügen im Durchschnitt über ein Anwendungsportfolio von etwa 200 Anwendungen
33 % von 200 bedeutet also, dass ein typisches Unternehmen durchschnittlich 66 moderne Anwendungen in seinem Portfolio hat. Legt man den von Sonatype ermittelten Durchschnittswert für Open-Source-Abhängigkeiten zugrunde, könnte ein durchschnittliches Unternehmen vor der Aufgabe stehen, 8448 verschiedene Open-Source-Abhängigkeiten abzusichern. Dabei gibt es mit ziemlicher Sicherheit Überschneidungen zwischen den Anwendungen. Container-native Anwendungen nutzen fast immer dieselbe Container-Orchestrierungsumgebung (Kubernetes ist derzeit der unangefochtene Marktführer unter den COEs). Daher ist der Aufwand im Hinblick auf die einzelnen Abhängigkeiten tatsächlich geringer – allerdings nicht insofern, als bei einer Sicherheitslücke jede einzelne Instanz aktualisiert werden muss.
Ohne weitere Berechnungen anzustellen, können wir uns wohl alle darauf einigen, dass die Absicherung der Software-Lieferkette angesichts der Größe der Anwendungsportfolios und der Einbindung von Open-Source-Abhängigkeiten heutzutage eine erhebliche Herausforderung darstellt.
Die neue Funktionalität von GitHub trägt dazu bei, indem sie „Schwachstellen findet und blockiert, die derzeit nur in der detaillierten Diff-Ansicht eines Pull Requests angezeigt werden“. Mit anderen Worten: Sie lässt sich in die CI/CD-Pipeline integrieren und sucht in Echtzeit nach bekannten Schwachstellen.
Cool. Das ist keine ungewöhnliche Funktion. DevSecOps treibt diese Art der „Shift-Left“-Sicherheitsstrategie bereits seit Jahren voran. Die meisten CI/CD-Pipelines können unabhängig von den eingesetzten Tools Sicherheitsprüfungen am Code durchführen. Allerdings bieten nicht alle die Möglichkeit, nach bekannten Schwachstellen zu suchen, die möglicherweise tief in Abhängigkeiten verborgen sind oder auf einen Logikfehler zurückgehen, der nicht so leicht zu erkennen ist.
Natürlich sollten Sie so viele Sicherheitsmaßnahmen wie möglich in die CI/CD-Pipeline integrieren, um Schwachstellen und Fehler auszumerzen, die Ihnen später auf die Füße fallen könnten. Aber darum haben wir diese Übung nicht durchgeführt.
SRE, Software und Lieferkettensicherheit
Ich weise deshalb ausdrücklich auf das Problem der bestehenden Software-Lieferkette hin, weil es sich nur noch verschärfen wird, wenn Unternehmen ihren IT-Betrieb mithilfe von SRE-Ansätzen modernisieren. Denn SRE-Praktiken basieren im Kern auf Automatisierung, die wiederum – wie Sie sicher wissen – von Software und Skripten abhängt, von denen viele – Sie ahnen es schon – Open Source sind.
Tatsächlich sollte es nicht überraschen, dass viele der von DevOps eingesetzten Open-Source-Tools auch von SREs verwendet werden. Vereinfacht man die Rollen und ihre Beziehung zueinander, sind SREs gewissermaßen DevOps für die Produktion. Während sich DevOps-Fachleute in der Regel auf die Pipeline für Software-Builds und -Releases konzentrieren, liegt der Fokus von SREs auf der Pipeline für den Softwarebetrieb. Dazu gehören nicht nur die Anwendungen, sondern auch Dienste für Anwendungssicherheit und -bereitstellung sowie Plattformen und Umgebungen (wie Core, Cloud und Edge). Der Aufgabenbereich von SRE-Fachkräften erstreckt sich über den gesamten IT-Stack, was die Absicherung der Software-Lieferkette erheblich erschwert.
Es versteht sich von selbst, dass die Sicherheit der Software-Lieferkette für alle Unternehmen ein wichtiges Thema sein sollte, da sie sich auf den gesamten Anwendungslebenszyklus auswirkt – von der Entwicklung über den Build und die Veröffentlichung bis hin zur Bereitstellung und zum Betrieb.
Und dies sollte Unternehmen, die ihre digitale Transformation erfolgreich bewältigen wollen, Anlass zur Sorge geben. Unternehmen weltweit stehen vor einem tiefgreifenden Wandel, der den innersten Kern der Organisation betrifft: die Unternehmensarchitektur.
Die meisten Unternehmensarchitekturen wurden vor Jahrzehnten auf der Grundlage von Frameworks entwickelt, die von der Annahme ausgingen, dass Ressourcen fest und unflexibel seien und das Rechenzentrum den Mittelpunkt der Geschäftswelt bilde.
Nichts davon trifft heute noch zu, und selbst wenn es so wäre, hat sich auch das Unternehmen verändert. Es wird zunehmend digital, und ein digitales Unternehmen mit datengesteuerten Prozessen lässt sich nicht angemessen durch eine Architektur abbilden, die für ein physisches Unternehmen mit menschengesteuerten Prozessen konzipiert wurde. Die Unternehmensarchitektur muss modernisiert werden, wobei neue Bereiche einbezogen werden müssen – etwa der SRE-Betrieb.
Und genau das tun sie. Unsere diesjährige Studie ergab, dass 37 % der Unternehmen bereits auf SRE-Betriebsmodelle setzen, um Anwendungen und den IT-Betrieb zu modernisieren, und weitere 40 % planen dies für die nächsten zwölf Monate. Dazu gehören Tools und Skripte, Software und Daten sowie ein kompletter Technologie-Stack, der diese neue Rolle innerhalb des Unternehmens unterstützt.
Und mit Software, Skripten und Technologie-Stacks gehen auch Lieferketten und Sicherheitsfragen einher. Eine wichtige Erkenntnis aus DevOps, die bei der Modernisierung des IT-Betriebs nicht außer Acht gelassen werden darf, ist, dass SRE-Praktiken viele der gleichen technischen Schulden und Sicherheitsprobleme mit sich bringen.
Die gute Nachricht ist, dass SRE-Abläufe – anders als DevOps und Build-Prozesse – für Unternehmen eine neue Praxis darstellen werden. Und die Einführung neuer Praktiken bedeutet auch, neue Arbeitsweisen zu etablieren – einschließlich der Integration von Sicherheit von Anfang an.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.