Sicherer Softwareentwicklungslebenszyklus (SSDLC)

Sicherheit ist ein wichtiger Bestandteil jeder Anwendung mit kritischen Funktionen. Dabei kann es um etwas so Einfaches gehen wie den Schutz Ihrer Datenbank vor Angriffen durch böswillige Akteure oder um etwas so Komplexes wie die Betrugsprüfung eines qualifizierten Leads, bevor dieser in Ihre Plattform importiert wird.

SDLC-Phasen

Der Softwareentwicklungslebenszyklus (SDLC) beschreibt, wie Softwareanwendungen entwickelt werden. Er umfasst üblicherweise die folgenden Phasen:

• Erfassung der Anforderungen

• Analyse der Anforderungen als Grundlage für das Design

• Design neuer Funktionen auf Basis der Anforderungen

• Entwicklung neuer Funktionen (Programmieren, um die Anforderungen zu erfüllen)

• Testen und Verifizieren neuer Funktionen – dabei wird bestätigt, dass sie die Anforderungen tatsächlich erfüllen

• Bereitstellung des neuen Projekts

Wartung und Weiterentwicklung dieser Funktionen nach der Veröffentlichung

7 Phasen des SDLC

SDLC-Methoden:

Agile Entwicklung:

Agile SDLC-Entwicklung setzt darauf, große monolithische Releases in mehrere kleine Releases aufzuteilen. Diese werden jeweils in zwei- oder dreiwöchigen Sprints umgesetzt. Automatisierung dient dazu, Anwendungen zu erstellen und zu verifizieren. So können Unternehmen deutlich schneller iterieren. Statt der seltenen, monolithischen Bereitstellungen, die für nach dem Wasserfallmodell entwickelte Anwendungen typisch sind, liegt der Fokus bei der agilen Entwicklung häufig darauf, mehrmals täglich neue Funktionen bereitzustellen und Software schrittweise statt auf einmal zu entwickeln.

Wasserfallmodell:

Das SDLC-Modell Wasserfall ist eine der ältesten und bekanntesten SDLC-Methoden und legte den Grundstein für diese SDLC-Phasen. Die 1970 entwickelten Phasen sind heute größtenteils unverändert. Die Softwareentwicklung hat sich jedoch grundlegend gewandelt und damit auch die Art und Weise, wie Software entsteht.

Warum ist ein sicherer SDLC wichtig?

Sicherheit spielt in jeder Phase des Softwareentwicklungslebenszyklus (SDLC) eine Rolle und muss Ihren Entwicklerinnen und Entwicklern bei der Umsetzung der Softwareanforderungen stets präsent sein. Mit gezieltem Einsatz und den richtigen SDLC-Sicherheitslösungen lassen sich Sicherheitsprobleme in der SDLC-Pipeline lange vor der Bereitstellung in der Produktionsumgebung beheben. Dadurch sinkt das Risiko, Sicherheitsschwachstellen in Ihrer Anwendung zu entdecken, und die Auswirkungen lassen sich minimieren, falls doch welche gefunden werden.

Das Ziel eines sicheren SDLC besteht nicht darin, herkömmliche Sicherheitsprüfungen wie Penetrationstests vollständig abzuschaffen. Vielmehr soll Sicherheit in den Verantwortungsbereich der Entwicklerinnen und Entwickler aufgenommen und ihnen ermöglicht werden, von Anfang an sichere Anwendungen zu entwickeln.

SDLC und Anwendungssicherheit

 Die Behebung eines Problems, das so spät im SDLC entdeckt wird, kann bis zu 100-mal mehr kosten als eine frühzeitige Behebung im Entwicklungsprozess. 

Wenn Entwicklerinnen und Entwickler Sicherheitsmaßnahmen frühzeitig in den SDLC integrieren, können sie potenzielle Sicherheitsprobleme proaktiv identifizieren und beheben. Dadurch sinken die Kosten für die spätere Behebung von Schwachstellen im Entwicklungsprozess erheblich. 

Welche Prozesse umfasst der sichere Softwareentwicklungslebenszyklus?

SDLC-Sicherheit betrifft jede Phase des Softwareentwicklungsprozesses. Das ist deutlich effizienter und kostengünstiger, als abzuwarten, bis sich diese Sicherheitsprobleme in der bereitgestellten Anwendung zeigen. Bei Prozessen für einen sicheren Softwareentwicklungslebenszyklus ist Sicherheit Bestandteil jeder SDLC-Phase.

Sicherheit in jede SDLC-Phase zu integrieren, erfordert vor allem eine entsprechende Einstellung, die alle Beteiligten mitbringen müssen. Die konkreten Sicherheitsaspekte und damit verbundenen Aufgaben unterscheiden sich jedoch je nach SDLC-Phase erheblich.

5 Phasen des sicheren Softwareentwicklungslebenszyklus

Jede SDLC-Phase muss zur Sicherheit der gesamten Anwendung beitragen. Wie das geschieht, ist je nach Phase unterschiedlich. Entscheidend ist: Die Sicherheit im Softwareentwicklungslebenszyklus muss dem gesamten Team stets präsent sein. Sehen wir uns beispielhaft den sicheren Softwareentwicklungslebenszyklus eines Teams an, das ein Portal zur Verlängerung von Mitgliedschaften entwickelt:

Phase 1: Anforderungen

In dieser frühen Phase werden Anforderungen für neue Funktionen von verschiedenen Stakeholdern erfasst. Dabei ist es wichtig, mögliche Sicherheitsaspekte der funktionalen Anforderungen für das neue Release zu identifizieren.

• Beispiel für eine funktionale Anforderung: Nutzerinnen und Nutzer müssen ihre Kontaktinformationen bestätigen können, bevor sie ihre Mitgliedschaft verlängern.

• Beispiel für einen Sicherheitsaspekt: Nutzerinnen und Nutzer dürfen nur ihre eigenen Kontaktinformationen sehen, nicht die anderer Personen.

Phase 2: Design

In dieser Phase werden die Anforderungen im Projektumfang in einen Plan dafür übersetzt, wie die Funktionen in der Anwendung aussehen sollen. Funktionale Anforderungen beschreiben in der Regel, was geschehen soll, während Sicherheitsanforderungen meist den Fokus darauf legen, was nicht geschehen darf.

• Beispiel für ein funktionales Design: Die Seite soll Namen, E-Mail-Adresse, Telefonnummer und Anschrift der Nutzerin oder des Nutzers aus der Datenbanktabelle CUSTOMER_INFO abrufen und auf dem Bildschirm anzeigen.

• Beispiel für ein Sicherheitsbedenken: Bevor Informationen aus der Datenbank abgerufen werden, müssen wir überprüfen, ob die Nutzerin oder der Nutzer über ein gültiges Sitzungstoken verfügt. Fehlt das Token, sollte die Person zur Anmeldeseite weitergeleitet werden.

Phase 3: Entwicklung

Bei der Umsetzung des Designs und seiner Überführung in die Praxis geht es meist darum, sicherzustellen, dass der Code aus Sicherheitssicht sauber geschrieben ist. Häufig gibt es etablierte Richtlinien für sicheres Programmieren und Code-Reviews, bei denen überprüft wird, ob diese Richtlinien korrekt eingehalten wurden. Code-Reviews können manuell oder automatisiert mithilfe von statischen Anwendungssicherheitstests (SAST) durchgeführt werden.

Moderne Anwendungsentwicklerinnen und -entwickler können sich jedoch nicht nur um den selbst geschriebenen Code kümmern, denn die meisten modernen Anwendungen werden nicht von Grund auf neu entwickelt. Stattdessen nutzen sie bestehende Funktionen, meist aus kostenlosen Open-Source-Komponenten, um neue Funktionen und Mehrwert für das Unternehmen so schnell wie möglich bereitzustellen. Tatsächlich bestehen über 90 % der heute bereitgestellten Anwendungen aus solchen Open-Source-Komponenten. Tools zur Software Composition Analysis (SCA) prüfen in der Regel diese Open-Source-Komponenten.

Richtlinien für sicheres Programmieren können in diesem Fall Folgendes umfassen:

• Verwendung parametrisierter, schreibgeschützter SQL-Abfragen zum Auslesen von Daten aus der Datenbank, um das Risiko zu minimieren, dass jemand diese Abfragen für böswillige Zwecke missbraucht

• Überprüfung von Benutzereingaben, bevor die darin enthaltenen Daten verarbeitet werden

• Bereinigung aller Daten, die aus der Datenbank an die Nutzerinnen und Nutzer zurückgesendet werden

• Prüfung von Open-Source-Bibliotheken auf Schwachstellen, bevor sie verwendet werden

Phase 4: Verifizierung

In der Phase der Verifizierung werden Anwendungen gründlich getestet, um sicherzustellen, dass sie dem ursprünglichen Design und den Anforderungen entsprechen. Diese Phase eignet sich auch hervorragend, um automatisierte Sicherheitstests mit verschiedenen Technologien einzuführen. Die Anwendung wird nur bereitgestellt, wenn sie diese Tests besteht. Häufig kommen in dieser Phase automatisierte Tools wie CI/CD-Pipelines zum Einsatz, um Verifizierung und Release zu steuern.

Die Verifizierung in dieser Phase kann Folgendes umfassen:

• Automatisierte Tests, die die kritischen Abläufe Ihrer Anwendung abbilden

• Automatisierte Ausführung von Unit-Tests, die die korrekte Funktionsweise der zugrunde liegenden Anwendung überprüfen

• Automatisierte Bereitstellungstools, die Anwendungsschlüssel dynamisch austauschen, damit sie in einer Produktionsumgebung verwendet werden können

Phase 5: Wartung und Weiterentwicklung

Mit der Veröffentlichung der Anwendung ist die Arbeit nicht abgeschlossen. Schwachstellen, die zuvor übersehen wurden, können noch lange nach der Veröffentlichung in der Anwendung entdeckt werden. Sie können sich im von den Entwicklerinnen und Entwicklern geschriebenen Code befinden, werden aber zunehmend auch in den zugrunde liegenden Open-Source-Komponenten einer Anwendung gefunden. Dadurch werden immer mehr „Zero-Day-Schwachstellen“ – zuvor unbekannte Schwachstellen – in der Produktionsumgebung von den Verantwortlichen für die Anwendung entdeckt.

Das Entwicklungsteam muss diese Schwachstellen dann beheben. In manchen Fällen kann dafür eine umfangreiche Überarbeitung der Anwendungsfunktionen erforderlich sein. Schwachstellen in dieser Phase können auch aus anderen Quellen stammen, etwa aus externen Penetrationstests ethischer Hacker oder aus Meldungen der Öffentlichkeit über sogenannte Bug-Bounty-Programme. Die Behebung dieser Probleme in der Produktionsumgebung muss eingeplant und in künftigen Releases berücksichtigt werden.

Die Vorteile eines SSDLC

Die wichtigsten Vorteile eines sicheren SDLC sind:

• Geringeres Risiko von Datenschutzverletzungen 

• Höhere Resilienz von Anwendungen 

• Mehr Vertrauen und Zuversicht bei den Nutzenden 

• Geringere Kosten für die Behebung von Problemen

Ein sicherer SDLC ist das beste Beispiel für eine sogenannte „Shift-Left“-Initiative. Dabei werden Sicherheitsprüfungen so früh wie möglich in den SDLC integriert.

So können Entwicklungsteams Releases besser planen und Probleme, die den Zeitplan beeinträchtigen könnten, leichter erkennen und beheben. Das ist besser, als nach der Bereitstellung der Anwendung in der Produktionsumgebung eine unangenehme Überraschung zu erleben. Ein SSDLC trägt daher dazu bei, dass Releases im Zeitplan bleiben.

Darüber hinaus werden die Sicherheitsmaßnahmen beim SSDLC grundsätzlich vom Entwicklungsteam selbst vorangetrieben. So können die Fachleute, die die Software geschrieben haben, Probleme beheben, statt dass ein anderes Team Fehler nachträglich korrigiert. Dadurch übernehmen Entwicklerinnen und Entwickler Verantwortung für die Gesamtqualität ihrer Anwendungen, sodass sicherere Anwendungen in der Produktionsumgebung bereitgestellt werden.

Der zusätzliche Aufwand für Sicherheitstests im SDLC-Prozess mag umfangreich und teuer erscheinen. Heute lässt sich jedoch ein Großteil davon automatisieren. Das gilt besonders für den Entwicklungsbetrieb (DevOps; mehr dazu weiter unten). Eine sichere SDLC-Umgebung erfordert eine regelmäßige Zusammenarbeit zwischen DevOps und den Entwicklungsteams, die die Anwendungsfunktionen implementieren. Diese Zusammenarbeit muss in den SDLC selbst integriert werden.

Wenn Entwicklungsteams diese Probleme frühzeitig beheben, können sie die Gesamtbetriebskosten ihrer Anwendungen senken. Werden Probleme erst spät im SDLC entdeckt, können die Entwicklungskosten für ihre Behebung um das Hundertfache steigen, wie die folgende Grafik zeigt.

IBM System Science Institute: Relative Kosten für die Behebung von Fehlern, 2010

Wie Abbildung 2 oben zeigt, ermöglicht der Wechsel zu einem sicheren SDLC Entwicklungsteams, schneller sichere Anwendungen zu entwickeln. Für Unternehmen kann sich diese Investition daher lohnen.

Wie lässt sich ein SSDLC sicherstellen?

Für einen sicheren SDLC müssen Sie sich darauf konzentrieren, wie die Anwendung funktioniert und wie die Entwicklerinnen und Entwickler Anforderungen in Anwendungscode umsetzen. Während der gesamten Anwendungsentwicklung muss Sicherheit dem Team stets präsent sein. Dafür können ein Kulturwandel innerhalb Ihrer Teams sowie automatisierte Prozesse und Prüfungen in jeder Phase der Softwareentwicklung erforderlich sein.

Wie sich ein SSDLC für eine Anwendung sicherstellen lässt, hängt stark von den Stärken und Schwächen des Entwicklungsteams im Bereich SDLC-Sicherheit ab. Daher lässt sich nur schwer ein einzelner Prozess für einen sicheren SDLC festlegen.

Da ein sicherer SDLC die Anpassung bestehender Prozesse, die Einführung neuer Tools und – noch wichtiger – einen Kulturwandel in mehreren Teams erfordert, sieht der Weg zu einem gut funktionierenden sicheren SDLC in jedem Unternehmen anders aus. Selbst innerhalb eines Unternehmens kann er sich zwischen verschiedenen Geschäftsbereichen unterscheiden.

5 Best Practices für einen sicheren SDLC

1. Schulen Sie Ihre Entwicklerinnen und Entwickler

Ein sicherer SDLC geht Hand in Hand mit mehreren verwandten Maßnahmen, darunter:

• Erstellung von Richtlinien für sicheres Programmieren

• Vermittlung von Sicherheitsbewusstsein und Schulungen zum sicheren Programmieren für Entwicklerinnen und Entwickler

• Klare Vorgaben dazu, wie schnell in der Produktionsumgebung entdeckte Probleme behoben werden müssen (auch als Remediation-SLAs bezeichnet).

Für eine wirksame SSDLC-Implementierung müssen nicht alle diese Maßnahmen umgesetzt werden. Doch ähnlich wie bei einem Puzzle müssen Sie genügend Teile zusammensetzen, bevor das Gesamtbild sichtbar wird.

2. Klare Anforderungen festlegen

Was auch immer Sie entwickeln: Es sollte leicht verständlich sein. Entwicklungsteams brauchen klare Anforderungen, die sich einfach umsetzen lassen. Das gilt für alle Sicherheitshinweise, Empfehlungen und Richtlinien. In Tests entdeckte Schwachstellen müssen sich leicht beheben lassen. Entscheidend ist, dass alle beteiligten Personen, Prozesse und Tools Lösungen vorschlagen, statt nur auf Probleme hinzuweisen.

3. Eine wachstumsorientierte Denkweise fördern

Da SSDLC die Arbeitsweise und Zusammenarbeit mehrerer Teams verändert, ist es wichtig, dass alle offen an diese Erfahrung herangehen und das Sicherheitsteam Entwickler dabei unterstützt, ihre Anwendungen selbst abzusichern.

4. Die Implementierung mit anderen Initiativen verknüpfen

Bei etablierten Anwendungen und Teams lassen sich SSDLC-Änderungen oft leichter umsetzen, wenn sie mit einer anderen Modernisierungsinitiative verknüpft sind – etwa einer Cloud-Transformation, einer DevOps-Initiative oder deren stärker sicherheitsorientierter Variante DevSecOps.

5. Zuerst die größten Probleme angehen

Konzentrieren Sie sich auf die wichtigsten Probleme und umsetzbaren Lösungen, statt jede entdeckte Schwachstelle zu beheben. Bei neueren oder kleineren Anwendungen ist es möglicherweise realistisch, jedes Sicherheitsproblem zu beheben. Bei älteren und größeren 

Anwendungen funktioniert das jedoch nicht unbedingt. Auch ein Triage-Ansatz kann hilfreich sein. Dabei geht es nicht nur darum, Sicherheitsprobleme von der Produktionsumgebung fernzuhalten, sondern auch darum, vorhandene Schwachstellen im Laufe der Zeit zu priorisieren und zu beheben.

SSDLC und DevSecOps

SSDLC und DevSecOps sind eng miteinander verknüpft, aber tatsächlich ergänzen sich die beiden Ansätze. Beide zielen darauf ab, Entwicklern mehr Verantwortung für ihre Anwendungen zu übertragen, damit sie mehr tun, als nur Code zu schreiben und zu testen, um funktionale Spezifikationen zu erfüllen.

Secure SDLC konzentriert sich darauf, wie eine Anwendung entworfen und entwickelt wird. DevSecOps verlagert die Verantwortung für die Produktionsumgebung jeder Anwendung von traditionellen IT-Teams zu den Entwicklern. So können sich Entwickler darauf konzentrieren, Build-, Test- und Release-Prozesse so weit wie möglich zu automatisieren.

DevOps und DevSecOps haben eine Revolution bei der Neudefinition der Rolle von Softwareentwicklern angestoßen. Dazu haben natürlich auch andere grundlegende Veränderungen wie Cloud-Transformationen beigetragen. Entwickler zu befähigen und Sicherheitstests zu beschleunigen, ist für den Erfolg der meisten modernen Unternehmen entscheidend. Dennoch wäre es ein Fehler, Anwendungssicherheit lediglich als Automatisierungsaufgabe zu betrachten. Stattdessen gilt es, kulturelle und prozessuale Veränderungen voranzutreiben, die das Sicherheitsbewusstsein und die Berücksichtigung von Sicherheitsaspekten bereits früh in der Entwicklung fördern. Das muss alle Phasen des Softwareentwicklungszyklus durchdringen – unabhängig davon, ob Sie den Ansatz SSDLC oder DevSecOps nennen.

Auf dem Weg in eine sicherere Zukunft

Herkömmliche Tests auf Schwachstellen in der Produktionsumgebung reichen für den Schutz Ihrer Anwendungen nicht mehr aus. Mit der Weiterentwicklung der Softwarebranche haben sich auch die Angriffsmethoden verändert. Um eine Anwendung sicher bereitzustellen und zu warten, muss jeder Schritt des Entwicklungsprozesses abgesichert werden. Dazu gehören Fragen zum Sicherheitsverhalten bereits in der Anforderungsphase, die Anpassung von Teamkultur und Arbeitsweisen an eine sicherheitsorientierte Denkweise, automatisierte Prüfungen im Deployment-Prozess und viele weitere Maßnahmen, die gemeinsam einen sicheren SDLC-Prozess ermöglichen.

Mit SSDLC können Sie Sicherheitsrisiken nach links verlagern und die Ursachen von Sicherheitsproblemen bereits in der Anforderungsphase angehen, statt sie erst in der Wartungsphase rückwirkend beheben zu müssen. Wenn Sie Best Practices für die SDLC-Implementierung befolgen (auch wenn Sie KI einsetzen!) und die Sicherheit in jeder Entwicklungsphase berücksichtigen, können Sie sicher sein, dass Ihre Anwendung deutlich besser geschützt ist.