Wenn man sich mit dem Secure Software Development Life Cycle beschäftigt, setzt man sich zwangsläufig mit Frameworks auseinander. In diesem Abschnitt werden drei eng miteinander verbundene Frameworks vorgestellt: SSDLC als grundlegendes Konzept, NIST SSDF als konkrete Umsetzungshilfe und OWASP SAMM als Instrument zur Bewertung des eigenen Reifegrads.
SSDLC – Secure Software Development Lifecycle
Im vorherigen Abschnitt haben wir das Konzept „Security by Design“ kennengelernt. Beim SSDLC und anderen Frameworks geht es gewissermaßen um die praktische Umsetzung dieses Konzepts – zusammengefasst im Begriff „Shift Left“.
Der SSDLC ist eine sicherheitsorientierte Erweiterung des klassischen Software Development Life Cycle (SDLC). Beim klassischen SDLC wurden Sicherheitsaspekte häufig erst am Ende des Prozesses berücksichtigt, also nach der Entwicklung oder sogar erst nach dem Deployment. Der SSDLC hingegen integriert Sicherheitsmaßnahmen in jede Phase des Entwicklungsprozesses. Genau das wird als „Shift Left” bezeichnet. Sicherheitsprüfungen finden so früh wie möglich statt, damit Schwachstellen erkannt und behoben werden, bevor sie in den produktiven Code gelangen.
Phasen des SSDLC
Die Phasen des SSDLC sind im Wesentlichen identisch mit denen des klassischen SDLC. Der Unterschied besteht darin, dass jede Phase um konkrete Sicherheitsaktivitäten ergänzt wird. Je nach Informationsquelle können sich die Begrifflichkeiten minimal unterscheiden. Auch die Anzahl der Punkte kann unterschiedlich sein, was wohl daran liegt, dass manche Quellen Phasen zusammenfassen oder aufteilen.
1. Planung (Requirements) – In der ersten Phase werden funktionale und sicherheitsrelevante Anforderungen definiert sowie potenzielle Risiken und Compliance-Vorgaben bewertet.
2. Design – Der Kernpunkt dieser Phase ist die Erstellung eines Architekturentwurfs. Hier kommen erste Sicherheitsmaßnahmen wie Threat Modeling und das Least-Privilege-Prinzip zum Einsatz.
3. Entwicklung – In dieser Phase werden die geplanten Sicherheitsmaßnahmen bei der Codeentwicklung implementiert und regelmäßig getestet. Typische Tool-Kategorien sind SAST (Static Application Security Testing) und SCA (Software Composition Analysis). Bei jedem Code-Commit können automatisierte Tools Open-Source-Komponenten auf bekannte Schwachstellen prüfen, ein Vorgang, der auch als Dependency Scanning bezeichnet wird.
4. Testing – Die fertige Software wird auf Schwachstellen und Sicherheitsfehler geprüft. Hier kommen DAST-Tools (Dynamic Application Security Testing) zum Einsatz, die die Anwendung im laufenden Betrieb testen.
5. Deployment – Die Software wird über eine gesicherte CI/CD-Pipeline ausgerollt – mit automatisierten Sicherheitsprüfungen in jeder Stufe. Vor dem produktiven Deployment durchläuft die Software typischerweise mehrere Vorproduktionsumgebungen (Dev > Test > Staging). Weitere wichtige Aspekte sind das Secrets Management (keine hardcodierten Credentials) und das Scannen von Infrastructure-as-Code auf Fehlkonfigurationen.
6. Betrieb und Wartung – Die letzte Phase umfasst die kontinuierliche Überwachung auf neue Bedrohungen und Schwachstellen, regelmäßiges Software-Patching, die Bewertung neuer Risiken sowie die Einhaltung der Compliance-Regeln.
NIST SSDF – Secure Software Development Framework
Im Februar 2022 hat Nationale Institut für Standards und Technologie (NIST) den ersten Release des Secure Software Development Frameworks (SP 800-218) veröffentlicht.
Das NIST SP 800-218 (Version 1.1, Version 1.2 ist als Entwurf verfügbar) ist ein Rahmenwerk, das konkrete Praktiken für die sichere Softwareentwicklung definiert. Das SDLC kann mit verschiedenen Entwicklungsmodellen (z. B. Agile, DevOps, Wasserfall) kombiniert werden. Es ist in vier Praktikgruppen unterteilt:
Prepare the Organization (PO) – Menschen, Prozesse und Technologien werden auf sichere Softwareentwicklung vorbereitet.
Protect the Software (PS) – alle Softwarekomponenten werden vor Manipulation und unbefugtem Zugriff geschützt.
Produce Well-Secured Software (PW) – Software wird mit minimalen Sicherheitslücken entwickelt und ausgeliefert.
Respond to Vulnerabilities (RV) – verbleibende Schwachstellen in veröffentlichten Software-Releases werden identifiziert, behoben und künftig verhindert.
Jede Praktik ist einheitlich strukturiert und enthält eine Beschreibung, konkrete Aufgaben zur Umsetzung, Implementierungsbeispiele sowie Referenzen zu anderen Standards.
Quelle: „Initial Public Draft“, Version 1.2: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf
Version 1.1: https://doi.org/10.6028/NIST.SP.800-218r1.ipd
OWASP SAMM – Software Assurance Maturity Model
Das SAMM (Software Assurance Maturity Model) des Open Worldwide Application Security Project (OWASP) ist ein Reifegradmodell, das Organisationen dabei unterstützt, den aktuellen Stand ihrer sicheren Softwareentwicklung zu bewerten und gezielt zu verbessern.
Im Gegensatz zu SSDLC oder SSDF beschreibt SAMM keine empfohlene Vorgehensweise, sondern liefert Bewertungskriterien und Entwicklungsziele für unterschiedliche Sicherheitsreifegrade: von „initial“ (Basismaßnahmen) bis hin zu „optimized“ (vollständig integriert).
Im Gegensatz zu SSDLC oder SSDF beschreibt SAMM keine empfohlen Vorgehensweise, sondern liefert Bewertungskriterien und Entwicklungsziele für unterschiedliche Sicherheitsreifegrade, von „initial“ (Basismaßnahmen) bis hin zu „optimized“ (vollständig integriert).
SAMM ist in fünf Hauptdomänen gegliedert, die den gesamten Entwicklungslebenszyklus abdecken:
- Governance – Sicherheitsstrategie, Metriken, Richtlinien, Schulungen
- Design – Threat Modeling, Sicherheitsanforderungen, Architekturanalyse
- Implementation – Sichere Programmierung und Bereitstellung, Fehlermanagemt
- Verification – Architekturbewertung, Security Testing, Vulnerability Management.
- Operations – Incident Management, Monitoring, Change Management.
Eine detaillierte Beschreibung der einzelnen Domänen findet sich :hier:
Geschäftliche Anforderungen
Die geschäftlichen Anforderungen sind eine Betrachtung der Sicherheit aus wirtschaftlicher Perspektive. Es ist deutlich günstiger, Sicherheit frühzeitig in den Entwicklungsprozess zu integrieren, als dies nachträglich zu tun. Die Beseitigung von Schwachstellen in späten Phasen kann nämlich um ein Vielfaches teurer sein als in der Designphase.
Hinzu kommen regulatorische und rechtliche Anforderungen. Die Implementierung von Compliance-Vorgaben oder verbindlichen Sicherheitsanforderungen muss von Anfang an in die Softwareentwicklung einfließen. Eine nachträgliche Änderung ist nicht nur aufwendig, sondern könnte im schlimmsten Fall gar nicht mehr möglich sein.
Und auch wenn es etwas übertrieben klingt: Sicherheit muss auf höchster Geschäftsebene als Kernanforderung aller Geschäftsbereiche verstanden werden – nicht als alleinige Aufgabe des Entwicklerteams.
Phasen und Methoden
Es gibt mehrere Modelle / Methoden der Softwareentwicklung. Die bekanntesten sind das Wasserfallmodell und die Agile-Methode. Darüber hinaus gibt es das V-Modell, das Spiralmodell, Rapid Application Development (RAD) und das inkrementelle Modell. Hier folgt nur ein kurzer Überblick zu einem sehr komplexen Thema.
Waterfall (Wasserfallmodell) handelt es sich um eine lineare Vorgehensweise. Erst wenn die vorherige Phase vollständig abgeschlossen ist, beginnt die nächste. Dies ist optimal für stabile Anforderungen, da es eine klare Struktur und umfangreiche Dokumentation ermöglicht. Bereits in der Designphase kann somit detailliert geplant werden. Genau diese „Starrheit“ macht das Modell für Projekte mit sich ändernden Anforderungen weniger geeignet.
Agile – basiert auf iterativen Zyklen (Sprints), kurzen Feedbackschleifen und enger Zusammenarbeit. Zu den Frameworks, die dem Agile-Umfeld zugeordnet werden, zählen beispielsweise Scrum oder Kanban. Im Gegensatz zum Wasserfallmodell ist Agile sehr anpassungsfähig, allerdings auf Kosten formaler Dokumentation.
Die Verbindung von „Agile“ und Sicherheit hat den Ansatz DevSecOps hervorgebracht, bei dem Sicherheit nicht als separate Phase, sondern als kontinuierlicher Bestandteil des gesamten Entwicklungs- und Betriebsprozesses integriert wird.