Was ist der sichere Lebenszyklus einer Softwareentwicklung?

Die Softwareentwicklung folgt traditionell einem linearen Ablauf: Planen, Programmieren, Testen, Bereitstellen. Jahrzehntelang wurde die Sicherheit erst in der Testphase berücksichtigt - nachdem bereits Tausende von Codezeilen geschrieben worden waren.

SSDLC stellt diesen traditionellen Ansatz in Frage, indem es die Sicherheit vom ersten Tag an in alle Phasen des Lebenszyklus der Softwareentwicklung (Software Development Lifecycle, SDLC) einbettet. Der SSDLC gliedert sich meist in neun Phasen: Anforderungen, Analyse, Planung, Design, Entwicklung, Dokumentation, Test, Bereitstellung und Wartung.

Teams erörtern zunächst Sicherheitsbedenken und funktionale Anforderungen, während Entwickler sicheren Code schreiben, indem sie validierte Eingaben und Authentifizierungsstandards verwenden. Die Tests laufen kontinuierlich, nicht nur vor der Veröffentlichung, oft durch automatisierte Codebewertungen.

Dieser „Shift Left“-Ansatz integriert die Sicherheit zu einem früheren Zeitpunkt in den Entwicklungsprozess und kann dazu beitragen, die Art und Weise zu verändern, wie Unternehmen Software entwickeln. Anstatt sich während der Testphase zu fragen: „Ist das sicher?“, stellen sich Teams die Frage: „Wie können wir das sicher gestalten?“, bevor sie die erste Codezeile schreiben.

Nehmen wir zum Beispiel eine Banking-Anwendung. Bei der klassischen Entwicklung könnte während der Tests vor dem Start eine Schwachstelle bei der SQL-Injection entdeckt werden, die dazu führt, dass die Entwickler Datenbankinteraktionen für Hunderte von Dateien neu schreiben müssen. Mit einem SSDLC erkennen Teams diese Schwachstelle viel früher, da Sicherheitsüberprüfungen während der Gestaltungs-, Entwicklungs- und Testphasen durchgeführt werden.

Aktuelle Daten zeigen, warum dieser proaktive Ansatz wichtig ist. Laut einer aktuellen Studie zur Sicherheit der Lieferkette stiegen die Angriffe in der Software-Lieferkette innerhalb von nur drei Jahren um 1300 %.¹

SSDLC kann Unternehmen vor diesen und anderen Cyberangriffen schützen, indem Schwachstellen früher erkannt werden – wenn die Fixes am einfachsten und kostengünstigsten sind. Es kann auch dabei helfen, die Einhaltung von Vorschriften wie der Datenschutz-Grundverordnung (DSGVO) und dem Health Insurance Portability and Accountability Act (HIPAA) zu gewährleisten.

Es gibt in der Regel neun SSDLC-Phasen, die dem SDLC-Modell eng folgen, mit dem Unterschied, dass jede Phase auch Sicherheitsaspekte einbezieht:

• Anforderungen.
• Analyse
• Planung
• Design
• Entwicklung
• Dokumentation
• Testen
• Bereitstellung
• Wartung

Die Teams besprechen die Funktionen der fertigen Software und definieren neben funktionalen Anforderungen auch Sicherheitsanforderungen von Anfang an – zum Beispiel die Implementierung von Verschlüsselung für sensible Daten und die Einführung rollenbasierter Zugriffskontrollen (RBAC). In diesen Besprechungen geht es auch um die Bewertung potenzieller Sicherheitsrisiken sowie die Einhaltung von Anforderungen wie den Datenschutzbestimmungen der DSGVO

Unternehmen quantifizieren potenzielle Sicherheitslücken und kartografieren ihre Bedrohungslandschaft, wobei sie eher auf Worst-Case-Szenarien als auf Best-Case-Annahmen achten. Zum Beispiel könnte eine App die Risiken von Datenlecks, Ransomware-Angriffen und Insider-Bedrohungen analysieren und für jedes einzelne Maßnahmen planen.

Sicherheitsteams und Stakeholder legen Rollen fest, weisen Ressourcen zu und definieren akzeptable Basiswerte auf der Grundlage potenzieller geschäftlicher Auswirkungen. Diese Planung ermöglicht die Priorisierung von Sicherheitslücken mit hohem Risiko bei gleichzeitiger Einhaltung der Entwicklungsfristen. So kann auch das Budget für Sicherheitstools und Schulungen eingeplant werden, bevor mit der Programmierung begonnen wird.

Die Designphase umfasst eine Bedrohungsmodellierung, eine systematische Analyse potenzieller Sicherheitslücken in der geplanten Architektur. Diese Vorgehensweise hilft dabei, sicherzustellen, dass ein sicheres Design in den Blueprint integriert wird – von der besten Plattform bis zur idealen Benutzeroberfläche – und nicht als kostspielige Nachrüstung hinzugefügt werden muss.

Entwickler wenden sichere Codierungspraktiken an, die auf sicheren Codierungsstandards basieren, welche von Unternehmen wie dem Open Web Application Security Project (OWASP) festgelegt wurden. Diese Standards können die Validierung aller Eingaben, die Implementierung von Authentifizierungstechniken, die Verwendung korrekter API-Aufrufe, das Scannen von Repositories und die sichere Behandlung von Fehlern umfassen.

Entwickler verwenden häufig integrierte Entwicklungsumgebungen (IDEs) mit Sicherheits-Plug-ins, um Probleme früher zu erkennen.

Teams bewerten Softwareabhängigkeiten, um Sicherheitsrisiken zu minimieren. Diese Sicherheitstests beginnen bereits während der Entwicklung. Ein Zahlungsabwicklungsmodul könnte beispielsweise während der Entwicklung Sicherheitstests unterzogen werden, nicht erst nach der Integration. 

Teams dokumentieren Sicherheitskontrollen und -prozesse für Audits, Compliance-Überprüfungen und Bewertungen, was eine schnelle Reaktion auf Vorfälle und eine fortlaufende Einhaltung regulatorischer Vorschriften ermöglicht.

Das Testen kombiniert Code-Überprüfungen mit Sicherheitstests. Die Teams validieren sowohl die Funktionalität als auch die Sicherheit vor der Bereitstellung.

Zu den Tests gehören statische Analysen, wie zum Beispiel statische Anwendungssicherheitstests (SAST), zur Analyse des Quellcodes ohne Ausführung des Programms sowie dynamische Anwendungssicherheitstests (DAST) zum Testen von Anwendungen während der Ausführung.

Fortgeschrittene Tests gehen ethische Hacker an, die zum Problem für den Code werden, Penetrationstests zur Validierung der Datensicherheit und Simulationen, bei denen APIs verwendet werden. Die Analyse von Softwarekompositionen (SCA) kann ebenfalls parallel durchgeführt werden, um anfällige Open-Source-Abhängigkeiten und Lizenzprobleme zu identifizieren.

Teams sichern die Bereitstellung – Server, Konfigurationen und Middleware – bevor sie die Software veröffentlichen. So wird verhindert, dass Sicherheitslücken durch eine falsch konfigurierte Infrastruktur entstehen.

Viele Teams erfassen auch Software-Telemetrie Metriken, Protokolle und Traces, um zu sehen, wie sich der Code in realen Umgebungen verhält. OpenTelemetry (OTel) ist ein Open-Source-Projekt der Cloud Native Computing Foundation (CNCF), das eine herstellerneutrale Erfassung und Weitergabe von Metriken, Protokollen und Traces ermöglicht und so konstante Signale über Dienste, Pipelines und Umgebungen hinweg sicherstellt.

Eine kontinuierliche Überwachung kann dafür sorgen, Bedrohungen und Sicherheitslücken frühzeitig zu erkennen und so eine schnelle Sanierung während des gesamten Softwarelebenszyklus zu ermöglichen. Diese Phase ist besonders dann entscheidend, wenn Zero-Day-Exploits verhindert und auf neu entdeckte Schwachstellen reagiert werden muss.

Unternehmen beginnen den sicheren Softwareentwicklungszyklus normalerweise mit etablierten Frameworks: umfassenden Methoden, die Sicherheitsbenchmarks, bewährte Sicherheitspraktiken und Tools zur Risikobewertung beinhalten. Einige der am häufigsten verwendeten Frameworks sind:

Das National Institute of Standards and Technology stellt von Behörden unterstützte Praktiken und Benchmarks für die sichere Entwicklung bereit, darunter das Secure Software Development Framework, NIST SP 800-218.

Dieses Framework hilft Unternehmen dabei, grundlegende Sicherheitsanforderungen für alle Entwicklungsteams festzulegen. Im Vergleich zu anderen Frameworks bietet es präskriptivere Standards und ist daher ideal für Regierungsauftragsnehmer und regulierte Branchen geeignet. Unternehmen, die mit Bundesbehörden zusammenarbeiten, müssen häufig aufgrund vertraglicher Verpflichtungen die NIST-Standards einhalten.

Das Open Web Application Security Project (OWASP) bietet ein offenes Framework an: das Software Assurance Maturity Model (SAMM).

OWASP SAMM hilft Unternehmen, bestehende Software-Sicherheitspraktiken zu bewerten und iterative Verbesserungsprogramme zu entwickeln, die auf ihre spezifischen Risikoprofile zugeschnitten sind. 

Aus diesem Grund wird es oft von Unternehmen bevorzugt, die flexible, reifebasierte Ansätze anstelle starrer Compliance-Anforderungen anstreben. Ein Startup kann beispielsweise mit grundlegenden Sicherheitspraktiken in entscheidenden Bereichen wie der Authentifizierung beginnen und dann schrittweise zu umfassenden Sicherheitstests ausweiten, sobald Team und Budget dies erlauben.

Die OWASP DevSecOps Guideline beschreibt die Implementierung der Pipeline mit integrierten Tools für Sicherheitstests: SAST, DAST, SCA (Software Composition Analysis) und IAST (Interactive Application Security Testing). Die Befolgung dieser Richtlinie kann dazu beitragen, Sicherheitstests einfacher in bestehende Pipelines für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) einzubetten, ohne die Entwicklungsabläufe zu unterbrechen.

Daher könnten Unternehmen, die ihre Sicherheit automatisieren möchten, ohne die Veröffentlichungszyklen zu verlangsamen, die OWASP DevSecOps-Richtlinie bevorzugen – etwa Fintech-Unternehmen, die täglich Updates bereitstellen und dabei PCI-DSS-Compliance aufrechterhalten.

Viele Unternehmen implementieren SSDLC durch DevOps und DevSecOps Praktiken, die Sicherheitstests automatisieren und in CI/CD-Pipelines integrieren, wodurch die Entwicklung beschleunigt und gleichzeitig die Sicherheitsstandards eingehalten werden. Durch den Einsatz von DevSecOps-Techniken sind Entwicklungsteams neben sicherem Design, Entwicklung, Betrieb und Wartung auch für die Sicherheit der Anwendung verantwortlich. Um schnell zu iterieren und Engpässe zu vermeiden, verwenden sie häufig Automatisierungen für Sicherheitstests.

SLSA („Salsa“) ist ein Community-Framework – ursprünglich von Google ins Leben gerufen und mittlerweile im Rahmen von OpenSSF – zum Schutz von Software-Lieferketten. 

Seine Richtlinien helfen Unternehmen dabei, Manipulationen zu verhindern, die Integrität von Artefakten zu überprüfen und die Verifikation von Entwicklungsprozessen und Abhängigkeiten zu automatisieren. Unternehmen, die die Sicherheit in der Lieferkette und die Nachweisbarkeit der Entwicklung optimieren möchten, können SLSA implementieren, um nachzuweisen, dass ihre Software während der Entwicklung nicht manipuliert wurde. Zum Beispiel muss ein Softwareanbieter, der Anwendungen vertreibt, den Kunden gegenüber nachweisen können, dass seine Releases authentisch und unverfälscht sind.

SSDLC kann Unternehmen mehrere entscheidende Vorteile bieten. 

Der „Shift Left“-Ansatz von SSDLC hilft Unternehmen, Sicherheitslücken zu erkennen und zu beheben, wenn dies noch einfach und kostengünstig möglich ist: während des Designs und der Entwicklung und nicht nach der Bereitstellung.

Eine Überprüfung in der Designphase könnte beispielsweise ergeben, dass eine geplante Architektur sensible Kundendaten über ein ungesichertes API-Endgerät offenlegen würde. Das frühzeitige Erkennen dieses Problems ermöglicht von Anfang an eine sicherere Architektur und vermeidet den potenziellen Schaden eines Data Breaches und die kostspielige Nachrüstung von Sicherheitsmaßnahmen.

Unternehmen können auch Kosteneinsparungen erzielen, wenn ein Datenleck auftritt. Laut dem Data Breach Kostenreport war ein DevSecOps-Ansatz (einschließlich SSDLC) der wichtigste Faktor bei der Senkung der Kosten für Data Breaches. Unternehmen, die diesen Ansatz verfolgen, verzeichneten um 227.192 US-Dollar niedrigere Kosten pro Data Breach.

SSDLC kann dazu beitragen, Ausfallzeiten zu vermeiden, indem Sicherheitsprobleme vor der Bereitstellung identifiziert werden, wodurch möglicherweise Notfallkorrekturen vermieden und die Softwarestabilität verbessert werden. Bedrohungsmodellierung und detaillierte Code-Überprüfungen in allen Phasen können diese Stabilität ebenfalls erhöhen.

SSDLC trägt zum Schutz der Software-Lieferkette bei, was die gesamte Infrastruktur und alle Personen umfasst, die mit dem Code in Berührung kommen – von der Entwicklung über die CI/CD-Pipeline bis hin zur Bereitstellung. Es kombiniert Risikomanagementpraktiken (wie Bedrohungsmodellierung und Abhängigkeitsscans) mit Cybersicherheit (wie Zugriffsbeschränkungen und Codesigning), um Schwachstellen im gesamten Lebenszyklus zu verhindern.

Zum Beispiel kann SSDLC Unternehmen dabei helfen, Software-Stücklisten (SBOMs) zu implementieren, um alle Komponenten und Abhängigkeiten zu verfolgen. Dieser Ansatz erleichtert die Identifizierung und Behebung von Schwachstellen, wenn diese in den Bibliotheken von Drittanbietern entdeckt werden.

SSDLC hilft Unternehmen bei der Einhaltung von Vorschriften, indem Sicherheitskontrollen und Dokumentationen in jede Entwicklungsphase integriert werden. Dieser Prozess ist für Unternehmen, die branchenspezifische Sicherheitsstandards wie die Datenschutz-Grundverordnung (DSGVO) , den Health Insurance Portability and Accountability Act (HIPAA) und den California Consumer Privacy Act (CCPA) konsequent einhalten müssen, von entscheidender Bedeutung. Eine zuverlässigere Compliance kann dazu beitragen, rechtliche Probleme und mögliche Bußgelder zu vermeiden. 

Bei der Implementierung des SSDLC müssen Entwicklungs-, Betriebs- und Sicherheitsteams häufig eng zusammenarbeiten, um verschiedene Sichtweisen in der Softwareentwicklung zu berücksichtigen. Diese notwendige Zusammenarbeit kann dabei helfen, Silos zwischen den Abteilungen abzubauen und Sicherheitsprobleme zu vermeiden, die später kostspielig werden könnten.

Trotz der vielen Vorteile können aber auch Herausforderungen auftreten, wenn Unternehmen SSDLC einführen. 

Stakeholder, die auf eine schnellere Markteinführung aus sind, sehen Sicherheitsanforderungen oft als Hindernisse für die Entwicklungsgeschwindigkeit. Sie könnten sogar darum bitten, die Sicherheitstests auf spätere Phasen zu verschieben. 

Dieser Ansatz kann zwar die anfängliche Entwicklung beschleunigen, führt aber oft zu kostspieligeren Verzögerungen, wenn Sicherheitslücken nach der Bereitstellung auftauchen.

Wird beispielsweise die Bedrohungsmodellierung während der Designphase vernachlässigt, können kritische Angriffspfade ungeschützt bleiben. Ohne eine systematische Bedrohungsanalyse könnten Teams Sicherheitslücken in Autorisierungssystemen, Datenzugriffskontrollen oder Serviceintegrationen von Drittanbietern übersehen – Schwachstellen, die in der Produktion exponentiell teurer zu beheben sind.

Da sich die Bedrohungslandschaft ständig weiterentwickelt, müssen Entwicklungsteams ihr aktuelles Sicherheitswissen auf dem neuesten Stand halten. Unternehmen ohne dedizierte Sicherheitskenntnisse benötigen möglicherweise mehr Schulungen, spezialisierte Mitarbeiter oder externe Berater, um SSDLC effektiv zu implementieren.

Beispielsweise wissen Entwickler, die neu im Bereich der sicheren Codierung sind, möglicherweise nicht, wann sie statische Analysetools einsetzen oder wie sie deren Ergebnisse interpretieren sollten. Ohne angemessene Schulungen könnten diese Tools kritische Schwachstellen aufzeigen, die unbehoben bleiben, oder Fehlalarme auslösen, die Entwicklungszeit verschwenden. Selbst erfahrene Entwickler müssen sich ständig weiterbilden, um über neue Bedrohungen und Sicherheitspraktiken auf dem Laufenden zu bleiben.

Komplexe Softwarearchitekturen mit zahlreichen Integrationen können mitunter aufwändige Sicherheitstools und -prozesse erfordern, was unter Umständen die Entwicklungszeit und -kosten erhöht. Zum Beispiel kann die Integration von IoT-Geräten, die unterschiedliche Datenformate und Kommunikationsprotokolle verwenden, weitere Angriffsflächen schaffen, die Teams sichern müssen.

Betrachten wir die Implementierung einer Verschlüsselungs-API, bei der die API mit minimalen Zugriffsrechten arbeiten und gleichzeitig verschiedene Anwendungsfälle unterstützen muss. Einige Dienste benötigen möglicherweise Verschlüsselungsfunktionen ohne Entschlüsselungsrechte. Dieser Prozess erfordert mitunter eine sorgfältige Planung in Bezug auf Zugriffskontrollen, Authentifizierung und Transport Layer Security (TLS), was die Komplexität rund um jeden Integrationspunkt erhöht, mit dem sich Teams befassen müssen, ohne die Sicherheit oder Funktionalität zu gefährden.