Shift-Left in der Softwareentwicklung, Teil 2 DevSecOps-Prozesse in der Praxis

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Der Shift-Left-Ansatz verschiebt Softwaretests in frühere Phasen der Anwendungsentwicklung. Doch einige Aspekte der Qualitätskontrolle entziehen sich der reinen „Linksverschiebung“. Und was dann?

Je weniger Fehler durch die Kontrollen in die Produktion durchschlüpfen, umso widerstandsfähiger wird die betreffende Software. Diesbezüglich besteht Einigkeit. Niemand möchte Quellcode mit Bugs auf die Produktion loslassen. Es stellt sich lediglich die Frage, welcher Weg am sichersten ins Ziel führt.

Stellt man sich die Anwendungsentwicklung als eine Zeitachse vor, geht es bei Shift-Left darum, die Problemsuche an den Anfang der Zeitachse zu verlagern, damit etwaige Erkenntnisse aus dem Testen der Software so früh wie möglich in die Planung, Entwicklung und das Debugging mit einbezogen werden können.

Unternehmen erhoffen sich von diesem Ansatz eine Handvoll nicht zu unterschätzender Vorteile, darunter:

• Kostensenkungen durch das frühzeitige Erkennen von Fehlern.

• Fokus auf die Kundenanforderungen, die zu einem besseren Produktdesign und Benutzererlebnis führt.

• Frühzeitiges, progressives, kontinuierliches Testen, welches auf lange Sicht die Anzahl der Fehler reduziert.

• Gesteigerte Effizienz und reduzierte technische Schulden, was auch wieder die Kosten senkt.

• Mehr Arbeitszufriedenheit, mehr Engagement und Langzeit-Mitarbeiterloyalität.

Einige Unternehmen verfolgen dieselben Ziele durch gegensätzliche Maßnahmen, nämlich indem sie den sogenannten Shift-Right-Ansatz (die Rechtsverschiebung) implementieren – mit ebenfalls beachtlichem Erfolg.

Shift-Left, Shift-Right, Shift-Everywhere

Bei Shift-Right geht es darum, das Testen, die Qualitätskontrolle und die Leistungsevaluierung einer Software in der Produktion unter realen Bedingungen durchzuführen, was das Verschieben dieser Aufgaben nach rechts auf der Zeitachse erforderlich macht. Shift-Right-Methoden stellen sicher, dass Anwendungen, die in der Produktion laufen, der realen Benutzerbelastung standhalten und gleichzeitig die Einhaltung eines hohen Qualitätsniveaus „im Feldeinsatz“ ermöglichen.

Bei Shift-Right testen Teams ihren Code in einer Umgebung, die reale Produktionsbedingungen nachahmt, statt in der Entwicklung, wo sich diese – und somit auch das Verhalten der Software – nicht simulieren ließen. Auf diese Weise können die Teams Problemen auf die Spur kommen, die eben nur zur Laufzeit auftreten.

Um einen Teil dieses Prozesses zu automatisieren, können Teams zum Beispiel API-Aufrufe tätigen und sich Praktiken der Observability zu Nutze machen, um Tests der Konfiguration zu automatisieren und das Verhalten der Anwendung zu überwachen.

Wie beim Shift-left besteht das Ziel des Shift-Right-Testing darin, die auftretenden Fehler klein zu halten, früh zu erkennen und schnell zu beheben (Engl. „fail small and fail fast“). Es wird davon ausgegangen, dass Probleme, die in der Laufzeitumgebung vor der Bereitstellung erkannt werden, leichter zu lösen sind als Probleme, welche die Kunden in der laufenden Produktion hätten erleben müssen.

Das Shift-Right-Verfahren wird Teil der kontinuierlichen Feedbackschleife, die für DevOps so typisch ist. Sie ermöglicht die Abstimmung der Entwicklung (Dev) und der Bereitstellung (Ops) enger aufeinander. Shift-Right-Tests sind besonders nützlich für jene Unternehmen, die eine progressive Bereitstellung mit verteilten Anwendungsarchitekturen praktizieren, indem die Entwickler neue Software-Funktionen schrittweise freigeben, um die Auswirkungen unvorhergesehener Probleme zu minimieren. Das Testen in einer produktionsbereiten Umgebung ist eine entscheidende letzte Phase, bevor die Funktionen als einsatzbereit erklärt werden können.

Der Shift-Right-Ansatz verhindert natürlich in keiner Weise Shift-Left-Praktiken, ganz im Gegenteil: die beiden Konzepte können sich gegenseitig ergänzen. Viele Organisationen sprechen hierbei vom Shift-Everywhere-Ansatz (Überallhin-Verschiebung). Shift-Left-Tests bieten die größten Vorteile für jene Entwicklungsprojekte, die mit der Verarbeitung großer Datenmengen einhergehen und eine Vielzahl von Datentypen handhaben.

Die Shift-Left/Shift-Right-Methodik unterscheidet sich diametral von der Art und Weise, wie das Testen in traditionellen „Wasserfall“-Modellen gehandhabt wurde. Die Wasserfallmethode, die viele Unternehmen ja längst schon verworfen haben, um konkurrenzfähig zu bleiben, folgt einem strukturierten Prozess bei dem die Anforderungen zuerst in Form von Spezifikationen „festgeklopft“ werden und dann in einer Reihe von Übergaben in Code einfließen.

In diesem Szenario schieben Entwickler das Testen in der Regel bis zur Freigabe für die Produktion auf. So können aber leicht Probleme übersehen werden, die Entwickler schnell hätten beheben könnten, während sie noch aktiv an betroffenen Code feilten. Dieser Ansatz führt also im Endeffekt zur Zeitverschwendung und trägt zu Problemen mit der Software in der Produktion bei.

Der Shift-Everywhere-Ansatz verkürzt die Bereitstellungszyklen und kann dennoch Code-Instabilitäten drastisch reduzieren. Indem die Unternehmen das Coden und Testen zu einer einzigen Aktivität zusammenfassen, können sie noch mehr Vorteile realisieren als durch den reinen Shift-Left- oder Shift-Right-Ansatz. Auf diese Weise lassen sich Fehler früher im Prozess erkennen und Software häufiger freigeben.

Beide Ansätze, Shift-Left und insbesondere Shift-Right, stützen sich auf das Konzept von Observability und setzen in der Praxis eine Implementierung von GitOps voraus. Dieser Ansatz der kontinuierlichen Softwareentwicklung und -Bereitstellung (Engl. operations, kurz: Ops) nutzt deklarativen Code unter Verwendung eines Versionskontrollsystems wie z. B. Git (einem sog. Source-of-Truth-System).

Die „Linksverschiebung“ der Sicherheit

Immer mehr Unternehmen wollen einen Shift-left in ihrer Anwendungsentwicklung und ihre Sicherheitsstrategie gleich mit abdecken. Dieser Entscheidung liegt die Erkenntnis zu Grunde, dass es nicht nur viel riskanter, sondern auch viel kostspieliger ist, Sicherheitsprobleme in der Codebasis zu finden und zu beheben, nachdem eine betroffene Version erst einmal in der Wildbahn der Produktion die Feuertaufe absolvieren muss.

Je länger ein Bug „in the wild“ währt, umso größer ist das Zeitfenster für mögliche Angreifer. Durch die Einführung einer „Shift-Left“-Sicherheitsstrategie verringert sich das Risiko einer erfolgreichen Attacke. Aber der Ansatz kann auch ganz leicht in die Binsen gehen. Die Linksverschiebung identifiziert nämlich Sicherheitslücken nur für jenen Code, der sich noch in der Entwicklung befindet.

Tiefe konzeptionelle Fehler und gravierende Mängel in Anwendungen und Technologien lassen sich nicht so einfach mal eben durch die Linksverschiebung der Testphase hinwegdiskutieren. Nachdem es die Codebasis in die Produktion geschafft hat, ist es mit der Linksverschiebung so eine Sache. Funktionen zur Laufzeitüberwachung bilden dann die erste Linie der Verteidigung. Im Falle von APIs ist das Problem besonders gravierend.

Programmierschnittstellen bilden Integrationspunkte zwischen der Codebasis und dem sie umgebenden Ökosystem. Sie sollten so wenig wie möglich geändert werden. Zugleich ist es aber nahezu unmöglich, alle möglichen Interaktionen mit umgebenden Lösungen außerhalb der Produktionsumgebung zu testen.

Bei APIs handelt es sich nicht nur um reinen Code, den man im Zuge der Linksverschiebung mal eben in der Entwicklungs- und Testphase so leicht „auf die Probefahrt“ nehmen kann, um Bugs in dem Code aufzudecken. APIs schaffen vielmehr eine Implementierung der Geschäftslogik zur Laufzeit eines Anwendungsökosystems.

Da die Geschäftslogik bei der statischen Codeanalyse nicht berücksichtigt werden kann, sind die Sicherheitstesttools in der Vorproduktionsphase nicht in der Lage, Unternehmen vor Angriffen auf APIs zu schützen. Kein Code-Scanner kann derzeit die Geschäftslogik vorab analysieren. So sind Unternehmen den wichtigsten Formen des API-Missbrauchs ausgesetzt, von Credential Stuffing über Account Takeover (ATO) bis hin zu Scraping.

Ein Unternehmen verfügt heute typischerweise über Hunderte oder sogar Tausende von APIs, die auch bereits in der Produktionsumgebung ihren Dienst verrichten; einige sind möglicherweise nach außen hin exponiert, wo Lösungen anderer Unternehmen darauf zugreifen. Angesichts der rasanten Entwicklung von APIs wissen die meisten Unternehmen nicht einmal, wie viele APIs sie betreiben, geschweige denn, wie man sie „reparieren“ oder absichern kann.

An welchen Stellen der Shift-left nicht greift

Um Schwachstellen in der Geschäftslogik zu erkennen, müssen Unternehmen ihre APIs in Aktion beobachten. Dies erfordert die Implementierung von Sicherheitsfunktionen außerhalb der Codebasis der betroffenen Anwendung. Unternehmen sind immer noch gut beraten, die fehlerfreie API-Implementierung durch den Einsatz geeigneter Sicherheitstools sicherzustellen, um etwa eine Fehlkonfiguration auszuschließen. Der Einschränkungen, die damit in Bezug auf die Gewährleistung der sicheren Bereitstellung der Geschäftslogik einhergehen, sollten sie sich dennoch bewusst sein.

Das Problem mit Log4j (Log4Shell), eine der potenziell gefährlichsten und am weitesten verbreiteten Sicherheitslücken in der gesamten Geschichte der IT-Industrie, wäre durch die Vorproduktionstests – sprich Shift-Left – niemals ans Tageslicht gekommen. Die ersten sechs Schwachstellen, die OWASP nach in der Reihenfolge ihrer Häufigkeit in der Liste der 10 wichtigsten API-Bedrohungen aufführt, lassen sich hingegen allesamt auf Lücken in der Geschäftslogik zurückzuführen, bei denen der Shift-Left-Ansatz nicht helfen kann.

Die Linksverschiebung der Sicherheit funktioniert für Anwendungen und Technologien, die noch nicht implementiert wurden und vollständig in der zu untersuchenden Codebasis eingeschlossen sind. In diesem Fall macht es Sinn, Sicherheitsrichtlinien und -parameter bereits zu Beginn des Entwicklungsprozesses festzulegen.

Die Anwendung von Shift-Left-Strategien auf neue, aufkommende Technologien bietet den größten Nutzen. Die Teams brauchen sich nicht darum zu kümmern, neue Sicherheitsfunktionen in bestehende Technologien in der Produktion nachzurüsten, da es der Code noch gar nicht so weit geschafft hat; nicht lange fackeln heißt hier die Devise.

Die Containersicherheit ist ein gutes Beispiel für ein effektives Shift-Left-Modell, das Unternehmen einen erheblichen Nutzen gebracht hat. Allerdings verlieren Shift-Left-Strategien schnell an Wert – und zwar dramatisch –, wenn sie auf Technologien angewendet werden, die bereits in der Produktionsumgebung ihren Dienst verrichten.

Ist die betroffene Codebasis bereits weit verbreitet, kann der Shift-Link-Ansatz zahlreiche neue Sicherheitslücken eröffnen und damit neue Risiken schaffen. Im Falle von APIs sehen sich Unternehmen mit einer weiteren Sicherheitsbedrohung konfrontiert, die ebenfalls in keiner Weise durch Shift-Left-Funktionen behoben werden kann: Angriffe auf die Geschäftslogik. (Das geht dann aus wie das Hornberger Schießen.)

Fazit

Eine verantwortungsvolle Linksverschiebung hat ihren festen Platz in der Softwareentwicklung. Sie kann die Sicherheit innerhalb der Anwendungsentwicklung auf ein neues Niveau heben. Der Shift-Left-Ansatz kann Entwicklern helfen, über die Sicherheit ihrer Anwendung strategisch nachzudenken.

Shift-Left ersetzt nicht den Schutz von Software zur Laufzeit der Bereitstellung, kann jedoch vorab die Entstehung neuer Sicherheitsbedrohungen verhindern und damit einen erheblichen Mehrwert schaffen. Einige Softwareschmieden verbinden Shift-Left mit Shift-Right für den ultimativen Erfassungsbereich: Shift-Everywhere.

(ID:49232640)