Illustration: Absmeier Gerlat

Die Integration von Sicherheit in den Entwicklungslebenszyklus einer Software ist seit Jahren ein viel beschworenes Mantra. Jetzt, da sich DevOps mehr und mehr etabliert, hat die Entwicklungsgeschwindigkeit um Größenordnungen zugelegt. Das macht die Aufgabe deutlich komplizierter und anspruchsvoller als noch vor einigen Jahren. In der Realität ist Geschwindigkeit der alles bestimmende Parameter. Die Aufgabe eines Sicherheitsteams beschränkt sich heute nicht mehr darauf, Sicherheit in den SDLC einzubauen, sondern sie in DevOps zu integrieren:

Dazu haben wir mit Natasha Gupta gesprochen, Integrated Application Security Solutions Manager in der Synopsys Software Integrity Group.

Inwiefern bringt die moderne Softwareentwicklung neue Herausforderungen für das Sicherheits- und Risikomanagement mit sich?

Natasha Gupta: Die moderne Softwareentwicklung hat zwei, der Natur nach unterschiedliche Probleme wirklich verändert. Das eine ist der Geschwindigkeitsaspekt. Insbesondere in Zusammenhang mit vielen Kerntechnologien, die DevOps implementieren. Etwa, was niedrige Latenzzeiten anbelangt und flinke, serverlose Architekturen, die Microservices nutzen.

Wenn wir uns die Komponenten einer Software ansehen und wie stark diese auf Open Source basieren, gibt es beim Thema Geschwindigkeit in der modernen Softwareentwicklung verschiedene Ansatzpunkte. Etwa Mechanismen, um eine Software schnell in die Produktion zu bringen. Erklärtes Ziel dieser Mechanismen ist natürlich, mehr Tempo in der Softwareentwicklung. Das hat aber seinen Preis, und ungeprüfte Schwachstellen finden leichter ihren Weg in Code auf Produktionsebene. Tatsächlich bestätigt eine Studie von ESG, dass sich viele Entwickler, zwischen 30 und 80 Prozent, mit genau diesem Problem auseinandersetzen. Schon allein, um mit dem aktuellen Druck auf die Geschwindigkeit überhaupt Schritt zu halten.

Die andere Hälfte des Problems betrifft das schiere Ausmaß des Sicherheits- und Risikomanagements. Man denke nur an die Vielzahl der Komponenten, die bei der Anwendungsentwicklung eine Rolle spielen. Angesichts aktueller Praktiken und der potenziellen Zahl von Software-Schwachstellen, beschränkt sich dieses Problem nicht auf individuell erstellte Anwendungen in großen Unternehmen. Es gibt Hunderte von Anwendungen, auf die Unternehmen angewiesen sind, ob es sich nun um Infrastrukturcode, kommerziellen Code oder Vertragscode handelt. Jede dieser vielen verschiedenen und untereinander verbundenen Applikationen ist potenzieller Träger einer ungeprüften Schwachstelle.

Was die Transparenz über diesen Risiko-Footprint anbelangt, ist das für die Anwendungssicherheit eine enorme Herausforderung. In jedem Unternehmen existieren dahingehend blinde Flecke. Nicht zuletzt, weil man versucht, sich mit unterschiedlichen Tools der Wahrheit anzunähern. Nur, was die

proprietäre Bewertung einer Schwachstelle und ihres Umfangs anbelangt, ebenso wie den Schweregrad und die Einschätzung, wie geschäftskritisch die Lücke für die betroffene Software tatsächlich ist – da hat jedes Tool seine eigene Wahrheit. Und was es heißt, sich durch diesen Flickenteppich unterschiedlicher Risikobewertungen in dem erwähnten Umfang zu wühlen, lässt sich an einem Konzern wie Amazon verdeutlichen: Hier geht jede Sekunde eine Software in die Produktivphase. Das ist ein enormes Maß an Skalierbarkeit. Welches der Grad an Transparenz ist, und welchen Preis man für Sicherheit und Risiko bezahlt, ist eine hoch komplexe Frage. Und die lässt sich als Entwickler nicht so leicht beantworten.

Keine DevSecOps-Initiative ist perfekt, und wird es vielleicht nie sein. Aber wenn es Probleme gibt, warum geraten DevSecOps-Initiativen entweder ins Stocken oder scheitern sogar zur Gänze?

NG: Das hat eine Reihe von Gründen. Dazu zählen die enorme Informationsflut und das Ausmaß an möglichen Ursachen für Software-Schwachstellen sowie Fehler in diesem Prozess. Aber auch die Identifizierung und der Triage-Aspekt sind immens komplex. Es existiert eine Vielzahl von

Datensilos, die sich aus unterschiedlichen Tools speisen. Für einen typischen AppSec-Entwickler heißt das, er muss diese Daten möglicherweise in eine manuelle Tabelle importieren und dann in einem benutzerdefinierten Data Lake nachverfolgen. Das ist wenig effizient. Und wenn Sie unterschiedliche Arten von Tests durchführen, aber nicht auf eine einheitliche Methodik zurückgreifen können, überlasten sie damit die Pipeline. Sie testen nach dem Zufallsprinzip, Sie testen an verschiedenen Punkten, an denen Sie vielleicht gar nicht testen müssen – das kann die Pipeline verstopfen, Builds unterbrechen und Latenz-Layer im Prozess verursachen. Nicht wenige Teams verzichten an diesem Punkt auf notwendige Sicherheitstests, weil sie mit dem Prozess nicht zurechtkommen. SLAs zu erfüllen kollidiert mit dem Geschwindigkeitsanspruch, über den wir bereits gesprochen haben.

Und es gibt noch einen weiteren kritischen Bereich bei DevSecOps. Das sind nicht nur die Prozesse und Technologien, sondern die Menschen und die vorherrschende Sicherheitskultur. Existierende Tools sind in weiten Teilen nicht in der Lage, das Sicherheitsverständnis unterschiedlicher Interessengruppen zu überbrücken und die Kontextebene einzubeziehen. Viele Fragen bleiben unbeantwortet: Welche Schwachstellen wurden behoben, welche überhaupt gefunden, wie hoch ist der Grad der Gefährdung und wie wahrscheinlich, dass diese Lücke ausgenutzt wird? Und eine weitere Frage, die besonders

für viele Entwickler die wichtigste ist, schließt sich an: Wer ist für die Gegenmaßnahmen maßgeblich in der Verantwortung?

Und »Wie kann ich die Schwachstelle fixen beziehungsweise beheben?«, »Welche Änderungen sind erforderlich und in welchem Ausmaß?« und »Gibt es eine Anleitung wie die Schwachstelle am besten zu beheben ist oder fehlt diese?« Anhand von Fragen wie diesen stellen wir immer wieder fest,

dass Unternehmen zwar um existierende Schwachstellen wissen, aber nicht, wie sie diese beheben können. Viele Schwachstellen auf Produktionsebene sind oft schon früh im Entwicklungs- und Produktionsprozess von Softwareprodukten bekannt und werden einfach nicht behoben. Entweder es fehlt an der Sicherheitskultur oder an den Tools.

Offensichtlich sind bei Weitem nicht alle DevSecOps-Initiativen erfolgreich. Was empfehlen Sie Unternehmen, wie sie das ändern können?

NG: Es gibt drei Prinzipien, die man im Hinterkopf behalten sollte, um viele der genannten Probleme und Schmerzpunkte, über die wir gesprochen haben, zu entschärfen. Das erste ist, den Code so schnell zu sichern, wie man ihn schreibt. Was das wirklich bedeutet, ist, ihre Tools so weit als möglich im Downstream zu verschieben, um proaktiv nach Sicherheitslücken und Schwachstellen suchen zu können. Gleichzeitig sollten sie sich für Tools entscheiden, die sich leicht in die jeweilige IDE integrieren lassen.

Zweitens sollte man den Test-Workflow kritisch überprüfen, um sicherzustellen, dass Sie die richtigen Tests zur richtigen Zeit durchführen. Dazu muss man sich einen Überblick über die zu testende Anwendung zu verschaffen. Man gleicht dann die Art der erforderlichen Tests damit ab, wie geschäftskritisch eine Anwendung ist, welche Änderung am Code erforderlich ist und welches die

spezifische Phase des SDLC ist, in der Sie auf dieses Problem hin testen möchten. Sie sollten auch berücksichtigen, ob es sich nur um eine geringfügige Änderung am Code handelt – etwa eine Schriftart. Oder handelt es sich um eine für den Funktionsumfang gravierende Änderung und existieren

Abhängigkeiten von anderen Anwendungen, die mit dieser Funktion interagieren? Wenn man über die richtigen Tests zur richtigen Zeit spricht, sollten diese Überlegungen unbedingt Eingang finden.

Aber das vielleicht wichtigste, dritte Prinzip ist die Fähigkeit, soviel Rauschen wie möglich herauszufiltern und sich auf die Daten zu fokussieren, die Sie durch intelligentes Testen gesammelt haben. Und zwar so, dass diese Daten effizient und nutzbringend integriert werden. Voraussetzung ist, Sie verfügen über ein einziges, einheitliches AppSec-System. Damit lösen Sie viele der Probleme, die wir diskutiert haben, einschließlich einer unzureichenden Sicherheitskultur, enormer Skalierungsanforderungen und disparater Quellen und Tools.