Der sichere Software Development Life Cycle Entwicklung und Sicherheit optimal synchronisieren

Anbieter zum Thema

Eskenzi PR Limited

SYNOPSYS GmbH

FAST LTA GmbH

SEPPmail - Deutschland GmbH

Die Art und Weise der Software-Entwicklung ändert sich ständig und die Bereitstellungszyklen werden immer schneller. Wenn die Anwendungssicherheit das Tempo von DevOps mithalten will, spielt Automatisierung eine Schlüsselrolle.

In den letzten fünf bis zehn Jahren hat sich die Softwareentwicklung dramatisch verändert. Große Software-Releases wurden in der Vergangenheit alle sechs bis 18 Monate veröffentlicht. Demgegenüber hat die aktuelle Release-Häufigkeit deutlich zugenommen. Das Wasserfallmodell der Softwareentwicklung hat sich in das verwandelt, was wir heute als DevOps-Modell kennen.

Als Konsequenz daraus hat DevOps die üblichen Sicherheitskontaktstellen des Wasserfallmodells verändert. Das betrifft im Wesentlichen die Art und Weise, wie man jetzt Anwendungssicherheit implementieren sollte. Um Reibungsverluste im Entwicklungsprozess zu vermeiden, gilt es, die Aktivitäten zur Anwendungssicherheit an die neue Welt der DevOps-Praktiken anzupassen. Diese Anpassungen müssen über Bedrohungsmodellierung, Entwurfsprüfung und zwei Wochen an Pen-Tests hinausgehen.

Einige Entwicklungsorganisationen veröffentlichen unter DevOps Software mittlerweile in täglichen, wöchentlichen oder zweiwöchentlichen Intervallen. Aber sie ringen immer noch mit älteren Methoden der Anwendungssicherheit. Das hat dazu geführt, dass die Entwicklung selbst nicht mehr synchron zu den Sicherheitstests verläuft.

Man kann schlecht einen zweiwöchigen Pen-Test für eine Software durchführen, die in wöchentlichen Intervallen veröffentlicht wird. Entwicklungsunternehmen sind darauf angewiesen, dass Sicherheit effektiv während des gesamten SDLC gewährleistet bleibt. Gut, schnell, frühzeitig und vor allem automatisiert.

Die verändernde Natur der Softwareentwicklung

Anwendungssicherheit muss sich also verändern, um aufzuholen: DevOps braucht Automatisierung, um effektiv mit Software-Release-Kadenzen im täglichen, wöchentlichen und zweiwöchentlichen Rhythmus klarzukommen, aber auch um den SDLC generell agiler zu machen. Beispielsweise wird DevOps schneller, wenn man automatisierte Pipeline Scans der Anwendungssicherheit in die Pre-Commit-Prüfungen einbettet. So wird bei jedem Einfügen von neuem Code seitens der Entwickler ein einheitliches Test-Level angewendet. Das wiederum führt zu einem vollautomatischen Check-in-Prozess.

Durch die Automatisierung sind die Entwickler aber nicht für jede Code-Änderung an das gleiche Sicherheitslevel gebunden. Wenn die Änderung beispielsweise nur eine geänderte Logo-Farbe betrifft, sind keine umfangreichen Sicherheitsscans oder manuellen Eingriffe nötig. Anders, wenn die Anwendung auf sensible Daten zugreift.

Anstatt Entwicklern vierteljährlich SAST-Ergebnisse zu liefern, erhalten sie die Ergebnisse einer automatisierten Code-Analyse sofort, wenn er Code einfügt (über bestimmte IDE-Plugins). Wenn man die Ergebnisse der Code-Analyse bereitstellt, während die Entwickler noch am Code arbeiten, hat das mehrere Vorteile:

• Der Code ist in den Köpfen der Entwickler noch frisch

• Man erkennt Codierungsprobleme früher und leichter, während die Entwickler noch mit dem Code beschäftigt sind

• Die Methode senkt das Risiko, dass Entwickler sich zu einem späteren Zeitpunkt nicht mehr an den Code-Kontext erinnern

Je mehr Automatisierung die Anwendungssicherheit bietet, desto besser ist es für die Open Source-Validierung, Container scannende Container, QS-Tests, API-Sicherheit und weitere Anwendungen mehr.

Automatisierte Sicherheit und Out-of-Band-Aktivitäten

Bei der Implementierung von Tests in DevOps muss man ein Gleichgewicht zwischen automatisierter Sicherheitsgewährleistung und Out-of-Band-Aktivitäten herstellen. Unter Umständen ist es angebracht, den automatisierten Sicherheitsprozess zu drosseln. Denn selbst in einem vollständig automatisierten DevOps-Prozess muss man gegebenenfalls langsamer vorgehen, um notwendige Änderungen vorzunehmen. Es stimmt, dass eine Code-Änderung, wie z.B. einfach nur die Änderung der Hintergrundfarbe einer Webanwendung, vielleicht nicht allzu risikoreich ist.

Es ist also kein Problem, diesen DevOps-Schritt zu automatisieren und die Änderung durchzuführen. Wenn die Webanwendung allerdings mit Kundendaten interagiert, ist es ratsam, das Tempo zu drosseln und den nächsten Application Security-Test „out of band“ zu nehmen. Dann kann man prüfen, ob man sich für das richtige Verfahren entschieden hat, bevor man ein unter Umständen vielfach höheres Risiko eingeht.

Für jedes Release einer Anwendung gibt es unterschiedliche Risiko- und Schweregrade. Entwicklungsunternehmen sollten das akzeptieren und sich an das potenzielle Risiko- und Schwerelevel jeder einzelnen Release anpassen. Dann müssen sie einen angemessenen Level von gewährleisteter Sicherheit und Sicherheitsabdeckung bieten, unabhängig davon, ob das innerhalb des DevOps-Workflows automatisiert, Out-of-Band oder in einer Kombination aus beiden stattfindet.

Leben auf der Überholspur

DevOps-Unternehmen eröffnen sich zwei Wege: Sicherheit auf der Überholspur oder Sicherheit auf der Kriechspur. Sie könnten beispielsweise einen automatisierten DevSecOps-Prozess im gesamten Entwicklungsunternehmen schaffen - die Überholspur. Nur gibt es keinen einheitlichen DevSecOps-Prozess für Unternehmen.

Das liegt daran, dass in einem Unternehmen unter Umständen Hunderte von Entwicklungsteams beschäftigt sind. Und nicht immer existiert ein standardisierter Prozess, dem alle Dev-Teams folgen können. Und es nicht trivial automatisierte Sicherheit für jedes Entwicklungsteam anzupassen.

Diejenigen, die sich auf der Überholspur in Sachen Sicherheit befinden, sollten einen Security Champion holen, der mit dem Entwicklungsteam zusammenarbeitet und ihm beim Verständnis der veränderten Application Security-Anforderungen hilft. Einschließlich einer konkreten Anleitung wie man in bestimmten Fällen Abhilfe schafft.

Auf der Kriechspur können einzelne Entwicklungsteams eventuell sogar weiterhin zügig arbeiten. Der Unterschied besteht darin, dass sie weiterhin die SDLC-Tools auswählen, die dem Team am sinnvollsten erscheinen. Sie sollten aber genauso zu den Tools greifen, die für die Anwendungssicherheit am sinnvollsten sind.

Fazit

Anwendungssicherheit darf nur ein akzeptables Maß an Reibungsverlusten für die Entwickler erzeugen, wenn DevSecOps funktionieren soll. Gibt es zu viele Reibungsverluste, umgehen Entwickler die Anwendungssicherheit, um schneller coden zu können.

* Boris Cipot ist Senior Sales Engineer bei Synopsys.

(ID:46579348)