Shift-Left-Testing: Ein Ansatz für mehr Sicherheit in DevOps

Cybersecurity ist heutzutage wichtiger denn je! Shift-Left-Security ist eine Möglichkeit, für mehr Sicherheit in der Softwareentwicklung zu sorgen und Ihr Unternehmen vor Angriffen zu schützen. Nicht nur nimmt die Häufigkeit der Cyberangriffe zu (die durchschnittliche Anzahl der Angriffe stieg im Jahr 2021 um mehr als 15 Prozent – ein Trend, der nicht aufzuhalten ist), die Bedrohungen werden auch zunehmend komplexer. Angreifer nutzen immer ausgefeiltere Angriffsmethoden, wie beispielsweise Social-Engineering-Angriffe, die 2021 um 270 Prozent zunahmen, und setzen Stealth-Viren ein, die darauf ausgelegt sind, herkömmliche Erkennungsmethoden zu umgehen.

Das bedeutet jedoch nicht, dass Unternehmen tatenlos zusehen müssen, wie sie mit einer deutlichen Zunahme und gesteigerter Intensität von Cyberangriffen konfrontiert werden. Sie können sich verteidigen, indem sie das Thema Sicherheit auf einem imaginären Zeitstrahl “nach links” verlagern – im Englischen “shifting security left”. Das hat nicht nur den Vorteil, dass Risiken früher erkannt werden, sondern es müssen auch weniger Zeit und Ressourcen für die Abwehr von Bedrohungen aufgewendet werden.

Lesen Sie weiter und erhalten Sie einen umfassenden Überblick darüber, was Shift-Left-Security bedeutet, warum sie nützlich ist und wie Sie sie in die Praxis umsetzen können.

Was ist Shift-Left-Security?

Shift-Left-Security bzw. Shift-Left-Testing ist ein Ansatz der Application Security, der darauf abzielt, Sicherheitslücken so früh wie möglich im Software-Development-Lifecycle zu erkennen und abzuschwächen.

Um zu verstehen, was damit gemeint ist, muss zuerst geklärt werden, wie der Software-Development-Lebenszyklus (auch als Software-Delivery-Lifecycle oder Software-Development-Pipelines bezeichnet) in DevOps funktioniert. In der Regel durchläuft jede neue Anwendung bzw. Anwendungsversion, die ein Team entwickelt, eine Reihe von Phasen:

Coding: Hier wird der Code für einzelne Funktionen oder Funktionseinheiten geschrieben.
Integration: Während dieser Phase werden Funktionen oder Änderungen in die Codebase der Hauptanwendung integriert.
Erstellung: Das betrifft den Prozess der Kompilierung des Quellcodes und der Abhängigkeiten zu ausführbaren Binärdateien.
Testen: In diesem Schritt führen Software Engineers Tests durch, um sicherzustellen, dass die Anwendungen die Leistungsanforderungen erfüllen.
Bereitstellung: Hier handelt es sich um den Prozess, bei dem die Anwendung in einer Produktionsumgebung zum Einsatz kommt.
Laufzeit: An diesem Punkt wird die Anwendung in der Produktion ausgeführt.

Source: https://jfrog.com/blog/shift-left-security-with-golang-in-vs-code/

Traditionell fanden Sicherheitstests in der Testphase des Delivery-Lifecycles statt. Manchmal wurden sie sogar erst dann durchgeführt, wenn eine Anwendung bereits in Produktion war. Im Rahmen der Vorgehensweise von Shift-Left-Security beginnen DevOps-Teams jedoch schon so früh wie möglich mit Sicherheitstests – idealerweise sobald ein neuer Quellcode geschrieben wurde.

Mithilfe von Shift-Left-Testing können Sie beispielsweise Ihren Quellcode scannen, um Abhängigkeiten in Ihrer Anwendung zu identifizieren, noch bevor der Code kompiliert und bereitgestellt wird. Dank dieser Informationen kann festgestellt werden, ob eine der Abhängigkeiten anfällige Open-Source-Komponenten in die Codebase einführt. Werden diese Schwachstellen nicht behoben, stellen sie beim Einsatz der Anwendung in der Produktion eine erhebliche Sicherheitsbedrohung dar.

Außerdem kann der Shift-Left-Ansatz Ihnen helfen, fehlerhaft konfigurierte Zugriffsrechte zu erkennen, die die Sicherheit einer Anwendung schwächen. Wenn die Zugriffskontrolle vor der Bereitstellung der Anwendung in der Produktion nicht aktualisiert wird, kann es zu Konfigurationsrisiken in der Produktionsumgebung kommen.

Shift-Left-Security bedeutet nicht, dass in der Produktion kein Security Monitoring mehr durchgeführt wird. Natürlich sollten Sie sich weiterhin darum bemühen, Bedrohungen in Produktionsumgebungen zu erkennen. Durch die Linksverschiebung des Themas Sicherheit, investieren Sie schon in einem früheren Stadium des Development-Lifecycles verstärkt in das Erkennen von Risiken und Bedrohungen. Je früher im Development-Lifecycle Sicherheitsprobleme gelöst werden, desto kosteneffizienter ist es für ein Unternehmen.

Der Ansatz der Shift-Left-Security spiegelt Shift-Left-Monitoring und -Testen wider, die dem Konzept Shift-Left-Security vorausgingen. Während beim Shift-Left-Monitoring und -Testen Leistungs- und Zuverlässigkeitstests so früh wie möglich im Software-Development-Lifecycle durchgeführt werden, liegt der Schwerpunkt beim Shift-Left-Testing auf Sicherheitstests zu Beginn des Development-Lifecycles.

Die wesentlichen Vorteile von Shift-Left-Testing

Unternehmen, die sich für Shift-Left-Security entscheiden, profitieren in mehrerlei Hinsicht:

Risiken frühzeitig erkennen

Der wohl offensichtlichste Vorteil von Shift-Left-Security besteht darin, dass der Ansatz Teams ermöglicht, Risiken frühzeitig zu erkennen. Dadurch haben Software Engineers mehr Zeit zu reagieren und können gleichzeitig den Schweregrad der (von einem Sicherheitsrisiko oder einer Schwachstelle ausgehenden) Bedrohung verringern.

Wenn Sie eine Zero-Day-Schwachstelle in einer bereits im Einsatz befindlichen App entdecken, müssen sofort Maßnahmen ergriffen werden, um sie zu beheben, da sie jederzeit ausgenutzt werden könnte. In dieser Situation besteht die Lösung oft darin, den Weg des geringsten Widerstands zu gehen (z. B. das Ausschalten der App, bis ein Update durchgeführt werden kann, um die Schwachstelle zu beheben), anstatt eine weniger störende Maßnahme zu setzen. Wenn das Problem jedoch schon während der Entwicklung erkannt wird, kann es mit minimalen Beeinträchtigungen für die Benutzer behoben werden, ohne es als kritische Situation behandeln zu müssen.

Bedrohungen in der Produktionsumgebung verringern

Die frühzeitige Erkennung von Risiken und Bedrohungen im Development-Lifecycle verringert auch die Wahrscheinlichkeit, dass Angreifer eine Sicherheitslücke oder eine Schwachstelle in einer Anwendung ausnutzen können, erheblich.

Zwar ist es möglich, dass Angreifer in Pre-Produktionsumgebungen eindringen, in denen Anwendungen entwickelt und getestet werden (wie z. B. beim Angriff auf SolarWinds), doch ist das Risiko eines aktiven Angriffs auf die Produktionsumgebung wesentlich höher. In der Produktion sind Anwendungen den End-Usern und in den meisten Fällen auch dem Internet ausgesetzt, so dass es für Angreifer in dieser Phase viel einfacher ist, Schwachstellen auszunutzen, als in einer Entwicklungs- oder Testumgebung, die in der Regel nicht direkt über das Internet zugänglich ist.

Bedrohungen schneller und kosteneffizienter beheben

Generell gilt: Je früher ein Sicherheitsrisiko oder eine Bedrohung erkannt wird, desto weniger Zeit und Aufwand ist für deren Behebung erforderlich.

Wenn Sie zum Beispiel ein Sicherheitsproblem entdecken, bevor der Code kompiliert und getestet wurde, können Sie diesen einfach aktualisieren. Sie verschwenden also keine Zeit mit dem Erstellen und Testen eines Anwendungs-Releases, das Sie letztendlich wieder verwerfen müssen. Wenn Sie ein Problem dagegen erst in der Produktion erkennen, müssen Sie die Ursache der Bedrohung ermitteln, den Quellcode aktualisieren, die App neu erstellen, die aktualisierte Version testen und schließlich bereitstellen – ein Prozess, der Wochen dauern kann. Demgegenüber beansprucht die Aktualisierung des Quellcodes schon vor dem Build der App möglicherweise nur wenige Minuten – unter der Voraussetzung, dass die Schwachstelle einfach zu beheben ist.

Und da Zeit Geld ist, spart eine schnellere Behebung von Problemen nicht nur dem Entwickler Arbeit, sondern senkt auch die Kosten für das Unternehmen. Wenn Entwickler mehr Zeit mit der Entwicklung neuer Anwendungen und Funktionen und weniger mit der Behebung von Sicherheitslücken verbringen, kann das Unternehmen mit den Programmierern im Personal mehr zustande bringen.

Das Risiko von Verzögerungen reduzieren

Je weiter der Code im Prozess der Software-Delivery-Pipeline vor der Erkennung eines Sicherheitsproblems fortgeschritten ist, desto größer ist das Risiko, dass ein Problem zu einer Verzögerung beim Release der Anwendung führt.

Auch hier gilt: Sicherheitsprobleme, die entdeckt werden, wenn ein Update noch als reiner Quellcode vorliegt, können oft schnell und einfach behoben werden. Wenn Sie jedoch warten, bis das Anwendungs-Release fertiggestellt ist – oder schlimmer noch, bis die Anwendung in Produktion ist – wird das Beheben des Problems zu einem viel längeren Prozess. Das wiederum erhöht das Risiko erheblich, dass Ihr Team die aktualisierte App nicht innerhalb der festgesetzten Frist bereitstellen kann.

Bessere Zusammenarbeit zwischen Entwicklern und Security-Teams

Die frühzeitige Erkennung von Sicherheitsrisiken und -bedrohungen trägt auch (vorausgesetzt natürlich, diese sind vergleichsweise leicht zu beheben und lösen keine Krisensituation aus) zu einer reibungsloseren Zusammenarbeit zwischen Entwicklern und Security-Teams bei. Es ist für beide Gruppen einfacher, sich das Problem zusammen anzusehen, es zu bewerten und gemeinsam an einer Lösung zu arbeiten, wenn das Problem bereits im Quellcode entdeckt wird.

Wenn ein Sicherheitsproblem jedoch erst in der Produktion erkannt wird, kann es passieren, dass Entwickler und Security-Engineers sich gegenseitig die Schuld zuschieben. Die Entwickler beschuldigen das Security-Team, das Problem nicht erkannt zu haben, während umgekehrt das Security-Team die Entwickler für die Verursachung des Problems verantwortlich macht. Keine gute Grundlage für eine konstruktive Zusammenarbeit.

Shift-Left-Security vs. DevSecOps

Da Shift-Left-Security die Zusammenarbeit zwischen Entwicklern und Security-Teams erleichtert, wird sie häufig im Zusammenhang mit DevSecOps erwähnt wird – einem Konzept, das die aktive Zusammenarbeit zwischen Entwicklern, Security-Teams und IT-Operations-Teams fördert.

Das bedeutet jedoch nicht, dass Shift-Left-Security und DevSecOps dasselbe sind. DevSecOps ist ein Ansatz bzw. ein Vorhaben, an dem sich Unternehmen bei ihrem Sicherheitskonzept orientieren können. Im Gegensatz dazu ist Shift-Left-Security eine spezifische Strategie.

Shifting Security ist eine ausgezeichnete Möglichkeit, DevSecOps zu operationalisieren. Die Umsetzung von Shift-Left-Security bedeutet jedoch nicht automatisch, dass man damit ein DevSecOps-Unternehmen wird. DevSecOps erfordert zusätzliche Vorgehensweisen, wie z. B. die Aufrechterhaltung aktiver Kommunikationskanäle zwischen Security-Teams und Entwicklungsteams sowie die Gewährleistung einer angemessenen Schulung der Entwickler, damit diese die Sicherheitsprobleme moderner Apps verstehen.

Shift-Left-Testing in der Praxis: Zwei Beispiele

Um zu verdeutlichen, wie Shift-Left-Security in der Praxis aussieht, sehen wir uns jetzt zwei Beispiele an, wie Shift-Left-Security Teams dabei helfen kann, riskante Situationen zu vermeiden.

Schwachstellen in Container-Images erkennen

Schauen wir uns zunächst ein Szenario an, in dem Ihr Team ein Container-Image bereitstellt, das auf Ubuntu basiert. Der Container wurde mit einem Dockerfile erstellt, das folgendermaßen aussieht:

FROM ubuntu:20.04

RUN apt-get update && \

apt-get install -y python3 && \

apt-get clean

CMD ["some-app"]

Wie jedes Betriebssystem ist auch Ubuntu anfällig für verschiedene bekannte Schwachstellen, die auch auf seiner Website offenlegt werden. Der herkömmliche Ansatz zur Erkennung dieser Schwachstellen würde darin bestehen, den Container in der Produktion zu implementieren und anschließend die Produktionsumgebung zu überprüfen, um festzustellen, ob anfällige Software ausgeführt wird.

Bei einer Shift-Left-Strategie können jedoch Tools eingesetzt werden, die das Dockerfile scannen, bevor das Container-Image erstellt wird. Diese Tools würden erkennen, dass das Dockerfile Ubuntu 20.04 als Basis-Image verwendet. Sie würden dann feststellen, ob Ubuntu 20.04 anfällig für bekannte Sicherheitslücken ist, die noch nicht gepatcht wurden. Falls das der Fall ist, können die Bedrohungen beseitigt werden, indem ein anderes Basis-Image verwendet wird oder die anfälligen Komponenten im Container manuell deaktiviert oder aktualisiert werden, indem dem Dockerfile Anweisungen hinzugefügt werden, diese Änderungen vorzunehmen.

Umgang mit schwachen Zugriffsrechten

Ein zweites Beispiel für Shift-Left-Security: Stellen Sie sich vor, Ihr Team plant die Bereitstellung eines Kubernetes-Pods, der wie folgt definiert ist:

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: my-app

spec:

template:

spec:

containers:

- image: my-image

name: my-app

...

securityContext:

allowPrivilegeEscalation: false

runAsUser: 0

Die letzte Zeile dieser Datei – runAsUser: 0 – weist den Pod an, dass er als Benutzer mit einer UID 0 ausgeführt wird. Wenn Sie sich mit Linux-UIDs auskennen, wissen Sie, dass die UID 0 für den Root-Benutzer steht. Daher würde dieser Pod als Root ausgeführt werden, was aus Sicherheitsgründen riskant ist, da einige Schwachstellen leichter ausgenutzt werden können (oder sich zu größeren Angriffen ausweiten könnten), wenn die Prozesse innerhalb eines Containers Root-Privilegien haben.

Wenn Sie einen Shift-Left-Ansatz verfolgen, könnten Sie Ihr Pod-Deployment-File vor der Ausführung scannen, um das Problem schnell zu erkennen und es dann einfach durch Änderung der RunAsUser-Konfiguration zu beheben. Wenn die Bereitstellung jedoch nicht zu einem frühen Zeitpunkt im Development-Lifecycle überprüft wird, würden Sie wahrscheinlich erst dann erfahren, dass Sie einen Container als Root ausführen, wenn er bereits in der Produktion ist. Außerdem wäre es zu diesem Zeitpunkt viel schwieriger, das Problem zu erkennen, da es keinen einfachen Weg gibt, die in einem Container verwendete UID von außen zu bestimmen.

Wie funktioniert Shift-Left-Security?

Shift-Left-Security ist eine Strategie, kein bestimmtes Instrument und auch keine bestimmte Methode. Sie kann auf unterschiedliche Arten umgesetzt werden.

Im Allgemeinen bedeutet die Umsetzung von Shift-Left-Security jedoch, dass Sicherheitstools eingesetzt werden, mit denen die Sicherheit des Codes während des Durchlaufs durch die Application-Delivery-Pipeline getestet und validiert werden kann. Beispiele für die wichtigsten Kategorien von Tools sind:

Software Composition Analysis (SCA): SCA-Tools decken Schwachstellen im Quellcode auf, etwa unsichere Open-Source-Abhängigkeiten.
Static Application Security Testing (SAST): SAST-Tools können auch einige Risiken im Quellcode identifizieren, wie zum Beispiel fehlende Eingabevalidierung.
Dynamic Application Security Testing (DAST): Dynamische Tests sind nützlich, um Sicherheitsrisiken aufzuspüren, nachdem Anwendungen kompiliert wurden und in einer Testumgebung ausgeführt werden.

Diese Tools können unabhängig voneinander eingesetzt werden. Die einfachere Herangehensweise besteht jedoch darin, eine SDLC-Security-Automation-Plattform zu nutzen, die Anwendungen in jeder Phase des Lebenszyklus automatisch schützt. Dadurch wird sichergestellt, dass DevOps-Teams so viele Risiken wie möglich so früh wie möglich erkennen können.

Früherkennung ist entscheidend

Der Shift-Left-Ansatz schützt Unternehmen nicht automatisch vor den vielen Cyber Security-Bedrohungen und -Risiken, denen sie heutzutage ausgesetzt sind. Aber sie lassen sich damit leichter erkennen, bevor sie zu einer Angriffsfläche für die Produktionsabläufe werden. Außerdem führt eine frühzeitige Erkennung auch zu einer schnelleren und einfacheren Behebung von Sicherheitsproblemen. Das ist ein Gewinn für Entwickler, Security-Teams und Unternehmen gleichermaßen.