Der Secure Software Development Lifecycle (SSDLC)

Sicherheit ist für jede Anwendung, die kritische Funktionen erfüllt, wichtig. Sie kann simple Aktionen wie den Schutz von Datenbanken vor Angriffen beinhalten oder aber komplexe Maßnahmen wie die Betrugsprüfung qualifizierter Leads vor dem Einpflegen in eine Datenbank.

Das Thema Sicherheit ist also in sämtlichen Phasen des Softwareentwicklungs-Lebenszyklus (Software Development Life Cycle, SDLC) von Belang und sollte in der Softwareentwicklung deshalb stets berücksichtigt werden. Dieser Artikel geht der Frage nach, wie ein sicherer SDLC aufgestellt wird. Zudem soll geklärt werden, wie Sie etwaige Probleme rechtzeitig erkennen, bevor sie in der Produktion zu Komplikationen führen.

Mit etwas Anstrengung können mögliche Sicherheitsmängel im SDLC bereits erkannt werden, bevor es an Bereitstellung und Produktion geht. So lässt sich das Risiko von Schwachstellen in der jeweiligen Anwendung reduzieren und zudem wird ihr Gefährdungspotenzial eingehegt.

Der sichere SDLC ersetzt dabei keine herkömmlichen Sicherheitsprüfungen wie z. B. Penetrationstests. Vielmehr werden Sicherheitsfragen als Teil des Entwicklungsprozesses betrachtet und die Entwicklungsabteilung wird in die Lage versetzt, die Anwendungssicherheit von Anfang an zu berücksichtigen.

Wieso ist ein sicherer SDLC so wichtig?

Ein sicherer SDLC ist deshalb relevant, weil die Anwendungssicherheit so wichtig ist. Denn die Zeiten, in denen Produkte ohne weitere Prüfungen auf den Markt geworfen werden konnten und Bugs dann einfach später behoben wurden, sind endgültig vorbei. Heute gilt es, potenzielle Sicherheitslücken in jedem einzelnen Entwicklungsschritt mit einzubeziehen. Und dazu muss das Thema Sicherheit anders in den SDLC eingebunden werden. Da sich theoretisch jeder Zugang zum Quellcode verschaffen kann, müssen Sie dafür sorgen, dass mögliche Anfälligkeiten bereits beim Programmieren erkannt werden. Somit ist ein sicherer SDLC-Prozess eine notwendige Voraussetzung, um die eigenen Anwendungen vor Hackern und anderen Angreifern zu schützen.

Die Entstehung des SDLC

Der Softwareentwicklungs-Lebenszyklus (Software Development Lifecycle, SDLC) beschreibt, wie Softwareanwendungen entwickelt werden. Meist setzt er sich aus den folgenden Phasen zusammen:

• Anforderungsanalyse

• Analyse der Anforderungen für Entwicklungsvorgaben

• Konzeption der neuen Features anhand dieser Anforderungen

• Entwicklung neuer Funktionen (Programmierung anhand der Anforderungen)

• Testen und Überprüfen der neuen Funktionen auf Erfüllung der Anforderungen

• Bereitstellung des neuen Projekts

• Pflege und Weiterentwicklungder Funktionen nach dem Release

Die sieben SDLC-Phasen

Die Wasserfall-Methode gilt als eines der ältesten und bekanntesten SDLC-Verfahren und als Ursprung der oben beschriebenen Phasen. Diese wurden im Jahr 1970 entwickelt und sind bis heute weitgehend unverändert geblieben. In der Softwareentwicklung ist es seitdem dagegen zu enormen Veränderungen gekommen.

Ursprünglich wurde Software für hochspezialisierte Anwendungszwecke entwickelt. Bis zur Veröffentlichung gingen bei der Wasserfall-Methode oft mehrere Jahre ins Land. Heutzutage steht dagegen ein möglichst hohes Innovationstempo bei gleichzeitiger Wahrung der Softwarefunktionen im Vordergrund. Die Unternehmen wenden sich zunehmend von der Wasserfall-Methode ab und nutzen stattdessen den agilen SDLC, der erstmals im Jahr 2001 vorgestellt wurde.

Bei der agilen Entwicklung werden Softwareprojekte in mehrere kleine Releases unterteilt, an denen im Rahmen von Sprints jeweils zwei bis drei Wochen lang gearbeitet wird. Anschließend werden die Anwendungen dann mithilfe automatischer Verfahren zusammengestellt und überprüft. So kommen die Programme natürlich viel schneller zur Marktreife. An die Stelle unregelmäßiger „monolithischer“ Bereitstellungen, wie sie für die Wasserfall-Methode charakteristisch sind, konzentrieren sich nun alle bei der agilen Entwicklung darauf, mehrmals täglich neue Funktionen fertigzustellen und die Software schrittweise zu entwickeln.

SDLC und Anwendungssicherheit

Wie ist es nun aber um die Sicherheit dieser Anwendungen bestellt? In der Zeit um 1970 war für die meisten Angriffe ein physikalischer Zugriff auf das Terminal nötig, auf dem die Anwendung lief. Die Welt war weitaus weniger vernetzt, was die Bedrohung durch externe Akteure in Grenzen hielt. Auch als nach und nach neue Entwicklungsverfahren eingeführt wurden, blieb die Sicherheitsfrage im SDLC eher ein Randthema.

Denn die Anwendungssicherheit fiel in den Aufgabenbereich der IT-Sicherheit, die auch für den Anwendungssupport zuständig war. Anfangs wurden die Anwendungen erst nach ihrer Veröffentlichung getestet. Die Tests erfolgten in Produktionsumgebungen und meist im Abstand von einem Jahr. Leider bedeutete dies auch, dass etwaige Schwachstellen teils monatelang von Angreifern ausgenutzt werden konnten, bevor sie überhaupt bemerkt und geschlossen wurden. Vor diesem Hintergrund entschieden sich immer mehr Unternehmen, neben den Produktionstests auch im Vorfeld der Veröffentlichung Sicherheitsprüfungen durchzuführen. Diese ergänzenden Tests mussten die Anwendungen rechtzeitig vor dem Release bestehen, damit der Programmiercode überhaupt in die Produktion gehen konnte.

Derartige Sicherheitsprüfungen nehmen oft mehrere Wochen in Anspruch und sorgen für entsprechende Verzögerungen im Release-Zyklus. Und vor allem lässt sich ihr Ergebnis unmöglich vorhersagen. So kann der Sicherheitstest lediglich einige wenige Schwachstellen offenlegen, die binnen weniger Tage behoben werden können. Es können aber auch mehrere Dutzend oder gar Hunderte von Schwachstellen auftreten. Diese Schwachstellen zu beheben, erfordert oftmals einen erheblichen Programmieraufwand und den Austausch ganzer Komponenten. Und die müssen dann natürlich erneut mit Blick auf die Anwendungs- und Sicherheitsanforderungen geprüft werden.

Diese Vorgehensweise wirft die Anwendungsentwicklung häufig um mehrere Wochen zurück, was die Einhaltung der ursprünglichen Veröffentlichungstermine dann völlig unmöglich macht. So entstehen enorme Reibungsverluste, die die Unternehmen zwingen, sich zwischen Pest und Cholera zu entscheiden: das Risiko in Kauf zu nehmen und eine Anwendung mit Schwachstellen auf den Markt zu bringen oder die gesteckten Ziele nicht zu erfüllen (oder sogar beides). Noch schlimmer ist, dass die Behebung von Problemen zu einem derart späten Zeitpunkt im SDLC bis zu hundertmal mehr kosten kann als eine frühzeitige Mängelbeseitigung (mehr dazu später).

Das Innovationstempo und die Häufigkeit von Software-Releases hat sich mit der Zeit immer weiter erhöht, was die Problematik zusätzlich verschärft. Dies hat dazu geführt, dass die Rolle der Anwendungssicherheit im Rahmen der Softwareentwicklung überdacht wurde und hat die Schaffung eines sicheren SDLC ermöglicht.

Welche Prozesse gehören zum Softwareentwicklungs-Lebenszyklus?

Ein sicherer SDLC berührt sämtliche Phasen der Softwareentwicklung. Er erfordert eine starke Konzentration auf Sicherheitsbelange. Zudem müssen Probleme fortlaufend in den Analyse- und Entwicklungsphasen berücksichtigt werden. Das ist deutlich effizienter – und auch kostengünstiger –, als abzuwarten, bis etwaige Sicherheitsmängel in einer bereits veröffentlichten Anwendung bemerkt werden. In einem sicheren Softwareentwicklungs-Lebenszyklus sollte das Thema Sicherheit also in sämtlichen Entwicklungsphasen mit einbezogen werden.

Die Berücksichtigung von Sicherheitsfragen in allen Phasen des SDLC ist vor allem eine Einstellungssache, die bei den Mitarbeitern verankert werden muss. Die Sicherheitserwägungen und entsprechenden Aufgaben unterscheiden sich dagegen deutlich von Phase zu Phase.

Die fünf Phasen des Softwareentwicklungs-Lebenszyklus

Jede einzelne Phase des SDLC leistet einen bestimmten Beitrag zur Anwendungssicherheit. In den einzelnen SDLC-Phasen kommen dabei oft unterschiedliche Verfahren zum Einsatz. Eine grundlegende Voraussetzung gibt es dabei aber. So wird von allen Mitarbeitern verlangt, Sicherheitsbelange stets im Blick zu behalten. Anhand eines Beispiels lässt sich veranschaulichen, wie ein Team im Rahmen eines sicheren SDLC ein Portal zur Verlängerung von Mitgliedschaften entwickelt:

Phase 1: Anforderungsanalyse

In dieser Frühphase werden die Erwartungen unterschiedlicher Akteure an die neu zu entwickelnden Funktionen erfasst. Dabei kommt es darauf an, auch Sicherheitsbelange mit Blick auf die funktionalen Anforderungen des neuen Release zu bestimmen.

• Funktionale Anforderung: Die Benutzer müssen ihre Kontaktdaten bestätigen, bevor sie ihre Mitgliedschaft verlängern können.

• Sicherheitserwägung: Den Benutzern sollen ausschließlich ihre eigenen Kontaktdaten angezeigt werden, nicht aber die von anderen Personen.

Phase 2: Konzeption

In dieser Phase werden die gesammelten Anforderungen in ein Konzept überführt. Dieses beschreibt ihre Umsetzung in der späteren Anwendung. In dieser Phase werden aus den Funktionsanforderungen meist Handlungsempfehlungen abgeleitet. Die Sicherheitserwartungen geben dagegen eher an, was nicht passieren darf.

• Funktionskonzept: Auf der Seite sollen Benutzername, E-Mail-Adresse, Telefonnummer und Anschrift aus der „CUSTOMER_INFO“-Tabelle in der Datenbank abgerufen und auf dem Bildschirm angezeigt werden.

• Sicherheitsproblem: Bevor die Daten aus der Datenbank abgerufen werden, muss überprüft werden, ob ein gültiger Session-Token vorhanden ist. Ist dies nicht der Fall, soll der Benutzer wieder auf die Anmeldeseite umgeleitet werden.

Phase 3: Entwicklung

Wenn es an Implementierung und Umsetzung geht, verlagert sich die Aufmerksamkeit meist in Richtung Codesicherheit. Für die sichere Programmierung liegen meist bereits etablierte Richtlinien vor. Zudem wird im Rahmen von Code Reviews kontrolliert, dass diese Richtlinien auch korrekt umgesetzt werden. Diese Quelltextüberprüfungen können manuell oder automatisch mithilfe von Technologien wie dem Static Application Security Testing (SAST) erfolgen.

Eine zeitgemäße Anwendungsentwicklung darf sich jedoch nicht ausschließlich auf den Quelltext beschränken. Denn die überwältigende Mehrheit moderner Anwendungen wird nicht aus dem Nichts heraus geschrieben. Vielmehr verlassen sich Entwickler auf bereits vorhandene Funktionen, die meist in Form kostenloser Open-Source-Komponenten daherkommen. So werden neue Funktionen erschaffen und damit einen Mehrwert für das Unternehmen in einer möglichst kurzen Zeitspanne. Tatsächlich setzen sich über 90 % der heutigen Anwendungen aus solchen Open-Source-Komponenten zusammen. Und die werden meist mithilfe von Verfahren der Software-Composition-Analysis (SCA) überprüft.

Richtlinien für sichere Programmierung können in diesem Fall die folgenden Anforderungen beinhalten:

• Die Verwendung parametrisierter SQL-Abfragen im Lesezugriff verringert bei der Datenbankabfrage die Gefahr von Missbrauch.

• Die benutzerseitigen Eingaben werden vor der Verarbeitung der enthaltenen Daten überprüft.

• Die vom Benutzer an die Datenbank übermittelten Daten werden bereinigt.

• Open-Source-Bibliotheken werden vor ihrer Verwendung auf Schwachstellen hin überprüft.

Phase 4: Verifizierung

In der Verifizierungsphase durchlaufen Anwendungen einen umfassenden Prüfzyklus, bei dem die Umsetzung der ursprünglichen Konzeption und der Anforderungen kontrolliert wird. Dies ist auch ein guter Ansatzpunkt für die Durchführung automatischer Sicherheitstests mit verschiedenen Technologien. Scheitern diese Tests, kann die Anwendung nicht eingesetzt werden. In dieser Phase kommen häufig automatische Verfahren wie CI/CD-Pipelines zum Einsatz, die Verifizierung und Freigabe kontrollieren.

Die Verifizierungsphase kann die folgenden Aktionen beinhalten:

• Automatische Tests unter Berücksichtigung der kritischen Anwendungspfade

• Automatische Ausführung von Unit-Tests zur Überprüfung der zugrunde liegenden Anwendung

• Automatisierte Bereitstellungstools, die dynamisch Anwendungsgeheimnisse für die Produktionsumgebung einbringen

Phase 5: Pflege und Weiterentwicklung

Nach dem Release ist das Thema Sicherheit noch lange nicht erledigt. Denn möglicherweise haben es einige Schwachstellen durch die Tests geschafft und werden erst geraume Zeit nach der Veröffentlichung bemerkt. Diese Schwachstellen können sich aus dem programmierten Code ergeben, gehen aber immer häufiger auf die in der Anwendung enthaltenen Open-Source-Komponenten zurück. Dies führt dazu, dass zuvor übersehene Anfälligkeiten oft erst im laufenden Betrieb bemerkt werden.

Und diese Anfälligkeiten müssen dann wiederum von der Entwicklungsabteilung nachgebessert werden – ein Unterfangen, das in einigen Fällen sogar eine komplette Neuprogrammierung der Anwendungsfunktionen erforderlich macht. Schwachstellen, die in dieser Phase bemerkt werden, können aber auch anderen Ursprungs sein. Zu denken ist dabei etwa an externe Penetrationstests ethischer Hacker oder Meldungen aus der Öffentlichkeit im Rahmen sogenannter „Bug-Bounty“-Programme für Programmfehler. Die Behebung derartiger Produktionsmängel muss dann bei künftigen Releases eingeplant und entsprechend berücksichtigt werden.

Die Vorteile des SSDLC

Ein sicherer SDLC ist ein sehr gutes Beispiel für den sogenannten Shift-Left. Der Begriff bezieht sich auf eine möglichst frühzeitige Einbindung von Sicherheitsprüfungen in die Softwareentwicklung.

Dieses Verfahren vereinfacht die Release-Planung und die Erkennung und Behebung von Problemen, die diese behindern könnten. Damit ist dieser Ansatz definitiv besser, als bei der Produktivsetzung unangenehme Überraschungen zu erleben. Der SSDLC sorgt also dafür, dass der ursprüngliche Zeitplan eingehalten wird.

Was den SSDLC außerdem ausmacht: Sämtliche Sicherheitsmaßnahmen werden vom Entwicklungsteam selbst geleitet. Auf diese Weise können Probleme von denselben Domain-Experten gelöst werden, die auch die Software geschrieben haben. So muss keine weitere Abteilung einbezogen werden, die dann erst im Nachgang die Fehler beseitigt. Somit tragen die Entwickler selbst die Verantwortung für die Anwendungsqualität. Und das wiederum bewirkt, dass sicherere Anwendungen in die Produktion gehen.

Der zusätzliche Aufwand, den die Sicherheitstests im Rahmen des SDLC-Verfahrens bedeuten, mag auf den ersten Blick enorm und vor allem kostenintensiv erscheinen. Das Gute daran ist aber, dass sich mittlerweile ein Großteil dieser Arbeit automatisieren lässt. Das gilt insbesondere für Entwicklungsabläufe (DevOps; mehr dazu unten). Ein sicherer SDLC erfordert eine regelmäßige Zusammenarbeit von DevOps und der für die Implementierung der Anwendungsfunktionen zuständigen Engineering-Teams. Und diese Zusammenarbeit muss ebenfalls in den Entwicklungszyklus eingebettet werden.

Werden Probleme frühzeitig im Prozess behoben, können die Entwicklerteams dadurch auch die Kosten ihrer Anwendungen senken. Werden Mängel dagegen erst später im SDLC erkannt, kann dies die Entwicklungskosten um den Faktor 100 steigern. Dies wird in dem folgenden Diagramm veranschaulicht.

IBM System Science Institute: (Relative Kosten der Mängelbeseitigung), 2010

Wie Abb. 2 anschaulich macht, befähigt die Umstellung auf SSDLC Entwicklerteams dazu, sichere Anwendungen schneller zu erstellen. Somit ist darin eine durchaus lohnenswerte Investition für Unternehmen zu sehen.

Wie lässt sich ein sicherer SDLC gewährleisten?

Ein sicherer SDLC setzt einen doppelten Schwerpunkt auf die Betriebsweise der Anwendung zum einen und die Umsetzung der Anforderungen in den Programmiercode zum anderen voraus. Das Thema Sicherheit muss allen Teammitgliedern während der gesamten Anwendungsentwicklung bewusst sein. Dies kann eine Weiterentwicklung der Unternehmenskultur und automatische Prozesse und Kontrollen in sämtlichen Phasen der Softwareentwicklung erforderlich machen.

Ob der SDLC tatsächlich sicher ist, hängt sehr stark von den Stärken und Schwächen des zuständigen Entwicklerteams ab. Dies macht die Festlegung auf den einen perfekten SSDLC-Prozess relativ schwierig.

Da für eine sichere Entwicklung auch Prozessänderungen, neue Tools und vor allem ein kultureller Wandel in mehreren Teams notwendig sind, muss jedes Unternehmen seinen eigenen Weg finden. Und sogar zwischen den einzelnen Unternehmenssparten kann sich der Ansatz durchaus unterscheiden.

5 Best Practices für einen sicheren SDLC

1. Entwicklerteams weiterbilden

Ein sicherer SDLC sollte von verschiedenen ergänzenden Maßnahmen begleitet werden, darunter die folgenden:

• die Aufstellung von Richtlinien für sichere Programmierung

• Sicherheitsschulungen für die Entwickler und Fortbildungen in der sicheren Programmierung

• die Aufstellung klarer Erwartungen und Zeitfenster für die Beseitigung der in der Produktion festgestellten Mängel (sog. Korrektur-SLA).

Nicht jede dieser Maßnahmen ist für einen effektiven SSDLC zwingend notwendig. Wie bei einem Puzzle benötigen Sie aber genügend Einzelteile, um ein stimmiges Gesamtbild zu erhalten.

2. Klare Anforderungen aufstellen

Ganz gleich, worum es geht – Verständlichkeit ist immer gut. Die Entwicklerteams sind auf konkrete, umsetzbare Erwartungen angewiesen. Dieser Tipp gilt für sämtliche Sicherheitshinweise, Empfehlungen und Leitlinien. Etwaige im Rahmen von Tests festgestellte Schwachstellen müssen einfach zu beheben sein. Es kommt vor allem darauf an, dass alle beteiligten Personen, Prozesse und Tools Lösungen liefern, anstatt lediglich Probleme aufzuzeigen.

3. Am Wachstum orientieren

Ein SSDLC verändert die Arbeitsweise und Interaktion mehrerer Teams. Deshalb kommt es darauf an, dass alle für diese Veränderung offen sind. Und die Sicherheitsabteilung muss bereit sein, die Entwickler zur Sicherung ihrer Anwendungen zu befähigen.

4. Umsetzung mit anderen Vorhaben verknüpfen

Bei gut eingespielten Anwendungen und Teams ist es oft einfacher, den SSDLC mit anderen Modernisierungsprojekten zu verknüpfen. Dabei ist etwa an die Verlagerung in die Cloud, DevOps-Projekte oder deren sicherheitsbezogene Ausprägung DevSecOps zu denken.

5. Die größten Probleme zuerst angehen

Konzentrieren Sie sich zunächst auf die größten Probleme und machbare Lösungen, anstatt sofort auf alle festgestellten Mängel einzugehen. Zwar ist es bei neuen und kleineren Anwendungen durchaus möglich, alle vorhandenen Sicherheitsmängel restlos auszumerzen. Dies gilt aber nicht unbedingt auch für ältere und umfangreichere Anwendungen. Auch ein Triage-Verfahren kann behilflich sein. Dabei geht es nicht so sehr darum, Sicherheitsprobleme vor der Produktivsetzung anzugehen. Der Schwerpunkt liegt vielmehr darauf, die vorhandenen Mängel einzuordnen und dann im weiteren Verlauf zu beheben.

Weitere Praxistipps, mit denen Sie die Sicherheit Ihres SDLC erhöhen können, finden Sie in unseren SDLC-Praxistipps.

SSDLC und DevSecOps

Die wechselseitige Beziehung zwischen SSDLC und DevSecOps ist ein wichtiges Thema. Beide Begriffe werden verwirrenderweise gelegentlich als Synonyme verwendet. Doch sind SSDLC und DevSecOps zwar eng miteinander verbunden, ergänzen sich aber vielmehr gegenseitig. Sowohl SSDLC als auch DevSecOps verfolgen das Ziel, den Entwicklern mehr Verantwortung für ihre Anwendungen zu übertragen. Diese sollen also mehr tun, als lediglich Programmiercode für bestimmte Funktionen zu schreiben und zu testen.

Beim SSDLC geht es vor allem darum, wie Anwendungen konzipiert und konstruiert werden. DevSecOps besteht dagegen vor allem darin, die Verantwortung für die Produktionsumgebung der jeweiligen Anwendung von den herkömmlichen IT-Teams an die Entwickler zu verlagern. Denn so können die sich voll darauf konzentrieren, ihre Entwicklungs-, Test- und Freigabeprozesse so stark wie möglich zu automatisieren.

DevOps und DevSecOps haben die Rolle der Softwareentwickler komplett verändert. Daran waren natürlich auch andere übergeordnete Veränderungen beteiligt, etwa das Aufkommen der Cloud. Zwar ist die Befähigung der Entwicklerteams und die Beschleunigung von Sicherheitstests für moderne Unternehmen durchaus ein Erfolgsfaktor. Es wäre dennoch falsch, in der Anwendungssicherheit lediglich ein weiteres Thema für die Automatisierung zu sehen. Vielmehr kommt es darauf an, Unternehmenskultur und Prozesse zu verändern, auf diese Weise für das Thema Sicherheit zu sensibilisieren und es im Entwicklungsprozess frühzeitig zu berücksichtigen. Und diese Veränderungen betreffen sämtliche Facetten des Softwareentwicklungs-Lebenszyklus – ganz gleich, ob Sie diesen nun als SSDLC oder DevSecOps bezeichnen.

Fazit

Die herkömmlichen Verfahren der Schwachstellenüberprüfung in der Produktion sind heute nicht mehr ausreichend, um sichere Anwendungen zu gewährleisten. Denn mit der Softwarebranche haben sich auch die Angriffsarten weiterentwickelt. Für sichere Anwendungen muss daher jeder einzelne Entwicklungsschritt abgesichert werden. Dies beinhaltet auch, das Thema Sicherheit bereits bei der Anforderungsanalyse einzubeziehen und Teamkultur und Verfahren auf das Thema Sicherheit einzustellen. Zudem gilt es, den Bereitstellungsprozess um eine automatische Verifizierung zu ergänzen und zahlreiche weitere Verfahren aufzustellen, um einen sicheren Entwicklungszyklus zu gewährleisten.

In einem SSDLC wird die Frage nach den Sicherheitsrisiken vorverlagert. So wird das Thema nicht erst bei der Softwarewartung, sondern bereits in der Anforderungsanalyse angegangen. Denn wer in sämtlichen Entwicklungsphasen auf die Sicherheit achtet, wird dafür am Ende mit deutlich sicheren Anwendungen belohnt.