Was ist ein Secure Software Development Lifecycle (SSDLC)?
Ein Secure Software Development Lifecycle (SSDLC) integriert sichere Entwicklungspraktiken risikobasiert in den verwendeten Softwareentwicklungslebenszyklus; er ist kein einheitlich normiertes Verfahren.
Technische Einordnung: Der allgemeine Begriff SSDLC bezeichnet einen Ansatz, nicht ein bestimmtes Prozessmodell. Das Secure Software Development Framework (SSDF) des NIST ist ein autoritatives Rahmenwerk für die Integration solcher Praktiken, aber nicht mit dem allgemeinen Begriff SSDLC gleichzusetzen.
Für wen ist ein SSDLC relevant?
SSDLC-Praktiken sind für Organisationen, Entwicklungsgruppen und Projekte relevant, die Software entwickeln oder entwickeln lassen. Sie können außerdem Gespräche mit Lieferanten bei der Beschaffung unterstützen. Daraus folgt jedoch kein universell verbindlicher persönlicher oder sachlicher Anwendungsbereich. Umfang und Auswahl der Praktiken werden an Geschäfts- oder Missionsanforderungen, Risikotoleranz und verfügbare Ressourcen angepasst.
Wann sollten Organisationen SSDLC-Praktiken einführen oder weiterentwickeln?
Autoritative technische Empfehlung: Ausgangspunkt ist die Entscheidung einer Organisation, sichere Entwicklungspraktiken in ihren vorhandenen SDLC zu integrieren oder bestehende Praktiken weiterzuentwickeln. Die Priorisierung erfolgt risikobasiert. Dabei sind Anforderungen, Risikotoleranz, Ressourcen, Kosten, Machbarkeit, Anwendbarkeit, Automatisierbarkeit und Abhängigkeiten zwischen Praktiken zu berücksichtigen.
Welche Bereiche deckt ein SSDLC ab?
NIST gliedert die sicheren Entwicklungspraktiken des SSDF in vier Bereiche: die Organisation vorbereiten (PO), Software schützen (PS), gut abgesicherte Software erzeugen (PW) und auf Schwachstellen reagieren (RV). Ein SSDLC reicht damit über Implementierung und Tests hinaus. Er umfasst auch organisatorische Vorbereitung, den Schutz von Softwareartefakten und den Umgang mit Schwachstellen in veröffentlichten Versionen.
Ist das NIST SSDF eine verbindliche Checkliste?
Nein. NIST beschreibt Praktiken, Aufgaben und Implementierungsbeispiele als anpassbaren und fortzuentwickelnden Ausgangspunkt. Die Implementierungsbeispiele sind weder einzeln noch in Kombination verpflichtend oder abschließend. Auswahl, Reihenfolge sowie Zeit- und Ressourceneinsatz müssen zum jeweiligen Risiko und Kontext passen.
Garantiert ein SSDLC schwachstellenfreie Software?
Nein. Ein SSDLC ist weder ein einzelnes Werkzeug noch ein starres Verfahren und kann Fehler oder Schwachstellen nicht vollständig ausschließen. Die Praktiken sollen Risiko, Häufigkeit und Auswirkungen von Schwachstellen verringern, einschließlich der Auswirkungen nicht erkannter oder nicht behobener Schwachstellen.
Welche Fristen oder Schwellenwerte gelten für einen SSDLC?
Der allgemeine technische Begriff SSDLC enthält keine universelle Frist, keinen einheitlichen Startpunkt und keinen quantitativen Schwellenwert. Zeitvorgaben oder Intervalle müssen gegebenenfalls aus dem gewählten Rahmenwerk sowie dem konkreten Vertrags-, Produkt- oder Regelungskontext gesondert ermittelt werden. Einzelne Praktiken oder externe Anforderungen können eigene Überprüfungs- und Reaktionsintervalle vorsehen.
Häufige Fehlannahmen
- „SSDLC und NIST SSDF sind dasselbe.“ Nein. SSDLC ist der allgemeine Ansatz; das SSDF ist ein konkretes autoritatives Rahmenwerk für dessen Ausgestaltung.
- „Ein Sicherheitstool führt bereits zu einem SSDLC.“ Nein. Sichere Entwicklung verbindet organisatorische Vorbereitung, Schutzmaßnahmen, Softwareerzeugung und Schwachstellenreaktion mit dem bestehenden Lebenszyklus.
- „Alle SSDF-Beispiele müssen vollständig umgesetzt werden.“ Nein. Die Beispiele sind nicht verpflichtend oder abschließend; Auswahl und Priorisierung erfolgen risikobasiert und kontextabhängig.
- „Ein SSDLC garantiert fehlerfreie Software.“ Nein. Ziel ist die Verringerung von Risiko, Häufigkeit und Auswirkungen von Schwachstellen, nicht deren garantierter Ausschluss.
- „Die Bezeichnung SSDLC gibt feste Termine und Kennzahlen vor.“ Nein. Solche Vorgaben ergeben sich nicht aus dem technischen Begriff selbst und müssen im konkreten Kontext bestimmt werden.
Was die Geschäftsleitung tun sollte
Praxisempfehlung: Die folgenden Schritte setzen die risikobasierte NIST-Systematik organisatorisch um; sie werden hier nicht als allgemeine verbindliche Pflicht dargestellt.
- Die vorhandenen Entwicklungspraktiken und Ergebnisse strukturiert mit den SSDF-Praktiken vergleichen.
- Erkannte Lücken anhand von Geschäfts- oder Missionsanforderungen und der Risikotoleranz priorisieren.
- Ressourcen unter Berücksichtigung von Kosten, Machbarkeit, Anwendbarkeit, Automatisierbarkeit und Abhängigkeiten zwischen Praktiken zuweisen.
- Verantwortlichkeiten für organisatorische Vorbereitung, Schutz der Software, sichere Erzeugung und Schwachstellenreaktion festlegen.
- Den Verbesserungsplan regelmäßig anhand neuer Erkenntnisse und veränderter Risiken fortentwickeln, statt ihn als einmalig abzuhakende Checkliste zu behandeln.
Für die Geschäftsleitung
Ein SSDLC betrifft Organisationen, die Software entwickeln oder entwickeln lassen, und kann auch die Zusammenarbeit mit Lieferanten unterstützen. Entscheidend ist kein starrer Katalog, sondern ein risikobasierter Verbesserungsplan für die vorhandene SDLC-Implementierung. Als Nachweis einer nachvollziehbaren Steuerung eignen sich insbesondere der dokumentierte Vergleich mit dem SSDF, die priorisierte Lückenliste, die begründete Ressourcenzuweisung und die festgelegten Verantwortlichkeiten. Ob darüber hinaus konkrete Vorgaben gelten, ist außerhalb des allgemeinen SSDLC-Begriffs für den jeweiligen Kontext gesondert zu klären.
Quellen
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, insbesondere Abstract.
- NIST Secure Software Development Framework Project, insbesondere „SSDF Practices“ und „SSDF Use“.
