In 6 Schritten zu DevSecOps

Dem trägt der DevSecOps-Ansatz Rechnung. Doch ebenso wie DevOps, ist dieser Ansatz kein Produkt, das man kauft, oder eine Lösung, die man implementiert. Es erfordert einen Kulturwandel im Unternehmen. Wie kann man vor diesem Hintergrund eine Strategie für DevSecOps formulieren? Ein Bericht des Analyseunternehmens Securosis im Auftrag von Veracode gibt einen Überblick über die Sicherheits-Tools und -Techniken, die in jeder Phase des Software-Lebenszyklus benötigt werden. Julian Totzek-Hallhuber, Solution Architect bei Veracode, fasst die wichtigsten Punkte zusammen:

Zunächst gilt es, die eigene Sicherheitsarchitektur gründlich zu analysieren, um zu verstehen, wie Anwendungen arbeiten und kommunizieren. Dazu gehören auch Richtlinien von Cloud Providern. Nachdem Unternehmen sich den vollen Überblick verschafft haben, können sie damit beginnen, verbindliche Operationsstandards zu definieren. Dazu sollten Dinge gehören wie Mindestanforderungen für Sicherheitstests und feste Zeitrahmen für die Fehlerbehebung. Außerdem muss hier die Entscheidung fallen, welche Sicherheitstest durchgeführt werden sollen und welche Metriken man heranziehen möchte, um den Erfolg zu messen.

In diesem Schritt geht es vor allem darum, sicherzustellen, dass die Entwicklungs- und Testumgebungen sicher sind. Dazu braucht es strikte Zugangskontrollen für CI/CD-Pipelines und zusätzliches Monitoring für Skripte im Hintergrund. Außerdem sollten Entwickler zu häufigen Bedrohungstypen geschult werden.

Wenn die Voraussetzungen geschaffen sind, kann man nun einen zentralen Punkt angehen: die Automatisierung des Testings. Dazu benötigen Entwickler sichere Repositories. Unternehmen sollten den Zugriff auf sichere und intern freigegebene Open-Source-Bibliotheken ermöglichen. Mit einer Kombination aus Analyse-Tools und Skripten können Verantwortliche dabei sicherstellen, dass Entwickler nur mit den freigegebenen Versionen arbeiten. Außerdem sollten Unternehmen Interactive Application Security Testing (IAST) etablieren. Mit dieser Methode können Schwachstellen in der Laufzeit identifiziert werden, bevor ein Code in Produktion geht.

Im Sinne des "Shift Left"-Ansatzes sollte man möglichst früh im Software-Lebenszyklus mit Tests beginnen. Es versteht sich von selbst, dass Unternehmen Fehler in ihrer Software finden wollen, bevor dies Kriminelle tun. Außerdem sollten auch die Testumgebungen kontinuierlich geprüft werden, um ihre Effizienz sicherzustellen. Mit verschiedenen, parallel durchgeführten Tests lassen sich die Methoden identifizieren, die das System verlangsamen und durch effektivere ersetzen.

Jetzt geht es darum, Sicherheit und Geschwindigkeit zu vereinen. Dazu sollten Unternehmen auch flexible On-Demand-Services aus der Cloud einsetzen. Produktionsumgebungen sollten außerdem gegen Datenlecks abgesichert werden, indem Tools wie Data Masking oder Tokenisierung zum Einsatz kommen, die dafür sorgen, dass Entwickler zwar alle Testdaten zur Verfügung haben, allerdings ohne Zugriff auf sensible Informationen.

Nun sollte man einzelne Testballons steigen lassen, um zu sehen, ob der Code, der vor dem Deployment funktionierte, auch im Deployment läuft. Muss das Deployment dann erweitert werden, können sich Unternehmen dieser drei Methoden bedienen: Beim Blue-Green oder Red-Black Deployment laufen alter und neuer Code parallel auf eigenen Servern. Treten Fehler auf, greifen die Load Balancer auf den alten Code zurück. Eine weitere Methode ist das sogenannte Canary Testing. Dabei werden einzelne Sessions auf neuen Code umgestellt. Werden dabei Fehler entdeckt, wird der entsprechende Code zurückgezogen und die Probleme werden behoben. Als dritte Methode können durch Feature-Tagging neue Code-Elemente aktiviert und deaktiviert werden. Wenn Ereignisfehler in einem neuen Codeabschnitt gefunden werden, können Entwickler die Funktion deaktivieren, bis das Problem behoben ist.

Im englischsprachigen Report Building an Enterprise DevSecOps Program finden Interessierte noch weitere Informationen zum Aufbau eines DevSecOps-Programms.