Der Trend zur Modernisierung der Betriebsabläufe wird den Bedarf an Sicherheit in der Software-Lieferkette erhöhen
Es ist heutzutage keine Überraschung, wenn Sicherheitsaspekte der Software-Lieferkette bedroht sind. Zuerst machte log4j Schlagzeilen und jeder versuchte verzweifelt, diese weitverbreitete und problematische Sicherheitslücke in der Software-Lieferkette zu beheben.
Vor Kurzem ist Spring4Shell auf unserem Radar aufgetaucht; eine weitere durch ein Framework verursachte Sicherheitslücke, die für Chaos in Unternehmen sorgt, die sich mit der Bedrohung auseinandersetzen müssen.
Daher war es einigermaßen erfreulich zu sehen , dass GitHub neue Funktionen einführte, die auf die Sicherheit der Software-Lieferkette abzielen. Besonders angenehm war es, nachdem ich Sonatypes neuesten Bericht zum Stand der Software-Lieferkette gelesen hatte. Darin werden Statistiken bereitgestellt, die jedem sicherheitsbewussten Techniker, unabhängig von seiner Funktion, Angst einjagen sollten. Bemerkenswert:
- Es sind mittlerweile 37 Millionen OSS-Komponentenversionen verfügbar
- 29 % der beliebten Projekte enthalten mindestens eine bekannte Sicherheitslücke
- 650 % mehr Cyberangriffe auf Open-Source-Anbieter als im Vorjahr
Diese Ergebnisse sind besonders beunruhigend, da der Bericht feststellte, dass „die durchschnittliche moderne Anwendung 128 Open-Source-Abhängigkeiten enthält“.
Sie wissen, dass ich kein Fan von Mathematik bin, aber lassen Sie uns trotzdem ein bisschen Mathe machen.
In der State of Application Strategy 2022 finden wir mehrere bemerkenswerte Statistiken:
- Moderne Anwendungen (containernative und mobil) machen durchschnittlich 33 % des Enterprise-App-Portfolios aus
- Unternehmen aller Branchen verfügen über ein durchschnittliches App-Portfolio von etwa 200 Anwendungen
33 % von 200 bedeutet also, dass ein typisches Unternehmen durchschnittlich 66 moderne Anwendungen in seinem Portfolio hat. Unter Verwendung des Open-Source-Abhängigkeitsdurchschnitts von Sonatype bedeutet dies, dass ein durchschnittliches Unternehmen die Last der Sicherung von 8448 verschiedenen Open-Source-Abhängigkeiten tragen könnte. Mit ziemlicher Sicherheit gibt es Überschneidungen zwischen den Anwendungen. Containernative Apps nutzen fast immer die gleiche Container-Orchestrierungsumgebung gemeinsam (Kubernetes ist derzeit der König der COE), und daher ist die Belastung im Hinblick auf spezifische Abhängigkeiten tatsächlich geringer, aber nicht in dem Sinne, dass jede dieser Instanzen im Falle einer Sicherheitslücke aktualisiert werden muss.
Lassen Sie uns ohne weitere Berechnungen einfach alle zustimmen, dass die Sicherung der Software-Lieferkette heutzutage angesichts der Größe der App-Portfolios und der Einbeziehung von Open-Source-Abhängigkeiten ein gewaltiges Unterfangen ist.
Die neue Funktionalität von GitHub trägt dazu bei, dieses Problem zu lösen, indem sie „Schwachstellen findet und blockiert, die derzeit nur im Rich Diff eines Pull Requests angezeigt werden.“ Mit anderen Worten: Es wird in die CI/CD-Pipeline integriert und sucht in Echtzeit nach bekannten Schwachstellen.
Cool. Das ist keine ungewöhnliche Fähigkeit. DevSecOps treibt diese Art von „Shift-Left“-Sicherheitsbewegung bereits seit Jahren voran. Die meisten CI/CD-Pipelines können unabhängig von den Tools Sicherheitsscans für Code durchführen. Allerdings verfügen nicht alle über die Möglichkeit, nach bekannten Schwachstellen zu suchen, die möglicherweise tief in Abhängigkeiten verborgen sind oder das Ergebnis eines Logikfehlers sind, der nicht so leicht zu erkennen ist.
Jetzt sollten Sie natürlich so viel Sicherheit wie möglich in die CI/CD-Pipeline integrieren, um Schwachstellen und Fehler auszumerzen, die Ihnen später auf die Füße fallen können. Aber das ist nicht der Grund, warum wir diese Übung gemacht haben.
SRE, Software und Lieferkettensicherheit
Der Grund, warum ich auf das Problem mit der bestehenden Software-Lieferkette hinweise, besteht darin, dass es sich nur noch verschlimmern wird, wenn Unternehmen ihren Betrieb mit SRE-Ansätzen modernisieren. Das liegt daran, dass SRE-Praktiken im Kern auf Automatisierung beruhen, die wiederum, wie Sie sicher wissen, auf Software und Skripten basiert, von denen viele – Achtung – Open Source sind.
Tatsächlich dürfte es keine Überraschung sein, dass viele der von DevOps verwendeten Open-Source-Tools auch von SREs verwendet werden. Wenn Sie die Rollen und Beziehungen vereinfachen möchten, sind SREs DevOps für die Produktion. Während DevOps-Experten sich normalerweise auf die Build- und Release-Pipeline der Software konzentrieren, liegt der Schwerpunkt von SREs auf der Softwarebetriebspipeline. Damit sind nicht nur die Apps gemeint, sondern auch die App-Sicherheits- und Bereitstellungsdienste sowie Plattformen und Umgebungen (wie Core, Cloud und Edge). Der Aufgabenbereich des SRE-Personals erstreckt sich über den gesamten IT-Stack, was ihre Aufgabe, wenn es um die Sicherung der Software-Lieferkette geht, erheblich erschwert.
Es genügt zu sagen, dass die Sicherheit der Software-Lieferkette für alle Organisationen ein Anliegen sein sollte, da sie sich auf den gesamten Anwendungslebenszyklus auswirkt – von der Entwicklung über die Erstellung und Veröffentlichung bis hin zur Bereitstellung und zum Betrieb.
Und es sollte für Unternehmen, die ihre digitale Transformation überleben wollen, ein Anliegen sein. In Unternehmen allerorts steht ein tiefgreifender Wandel bevor, der sich auf das Herzstück der Organisation auswirkt: die Unternehmensarchitektur.
Die meisten Unternehmensarchitekturen wurden vor Jahrzehnten auf der Grundlage von Frameworks entwickelt, die auf der Prämisse basierten, dass die Ressourcen festgelegt und unflexibel seien und das Rechenzentrum im Mittelpunkt des Geschäftsuniversums stehe.
Nichts davon trifft heute mehr zu, und selbst wenn es so wäre, hat sich auch das Geschäft verändert. Dieses Geschäft wird heute zunehmend digitaler, und ein digitales Geschäft mit datengesteuerten Prozessen kann nicht angemessen durch eine Architektur dargestellt werden, die ein physisches Geschäft mit von Menschen gesteuerten Prozessen abbildet. Die Unternehmensarchitektur muss modernisiert werden und dabei müssen neue Domänen integriert werden – wie die des SRE-Betriebs.
Und das sind sie. Unsere diesjährige Untersuchung ergab, dass 37 % der Organisationen bereits SRE-Operationen eingeführt haben, um Apps und Abläufe zu modernisieren, und weitere 40 % planen dies in den nächsten 12 Monaten. Das bedeutet Werkzeuge und Skripte, Software und Daten sowie einen ganzen Stapel an Technologien, die diese neue Rolle innerhalb der Organisation unterstützen.
Und mit Software, Skripten und Stapeln kommen Lieferketten und Sicherheit. Und eines haben wir von DevOps gelernt und können es bei der Modernisierung des Betriebs nicht ignorieren: SRE-Praktiken bringen viele der gleichen technischen Schulden und Sicherheitsherausforderungen mit sich.
Die gute Nachricht ist, dass SRE-Operationen im Gegensatz zu DevOps und Build-Prozessen eine neue Praxis für Unternehmen sein werden. Und die Einführung neuer Praktiken erfordert die Einführung neuer Betriebsweisen – einschließlich der Einbeziehung der Sicherheit von Anfang an.