01Was ein Secure SDLC ist – und warum Testen allein nicht genügt
Ein SSDLC ist kein zusätzliches Projekt, sondern eine Prozessdisziplin: Sicherheitsanforderungen, -aktivitäten und -verantwortlichkeiten werden entlang aller Phasen der Softwareentwicklung definiert – von Anforderungen über Design, Implementierung, Test und Release bis zum Betrieb. Der Grundgedanke ist, Schwachstellen möglichst früh zu verhindern oder zu erkennen, weil ihre Behebung mit jeder späteren Phase aufwendiger wird („Shift Left“). Punktuelle Sicherheitstests kurz vor dem Release bleiben wichtig, prüfen aber nur das Ergebnis; ein SSDLC adressiert zusätzlich die Ursachen im Prozess. Das Vorgehen ist unabhängig vom Entwicklungsmodell und lässt sich in klassische wie agile oder DevOps-Organisationen integrieren.
02NIST SSDF (SP 800-218): der Referenzkatalog sicherer Entwicklungspraktiken
Das Secure Software Development Framework des NIST (SP 800-218, Version 1.1, final seit Februar 2022) beschreibt 19 Practices mit 42 Tasks in vier Gruppen: „Prepare the Organization“ (PO), „Protect the Software“ (PS), „Produce Well-Secured Software“ (PW) und „Respond to Vulnerabilities“ (RV). Jede Practice enthält Umsetzungsbeispiele und Referenzen auf andere Standards, ist aber bewusst technologie- und methodenneutral formuliert – das SSDF eignet sich damit als gemeinsame Sprache zwischen Entwicklung, Sicherheit und Einkauf. Seit dem 17. Dezember 2025 liegt zudem der Entwurf der Version 1.2 (SP 800-218r1, Initial Public Draft; Kommentierungsfrist endete am 30. Januar 2026) vor; er ist noch nicht final und sollte entsprechend nur als Ausblick behandelt werden.
03SP 800-218A: SSDF-Profil für generative KI
Für die Entwicklung generativer KI und sogenannter Dual-Use Foundation Models hat NIST im Juli 2024 die Ergänzung SP 800-218A veröffentlicht („Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile“). Das Community Profile erweitert die SSDF-Practices um KI-spezifische Aufgaben, Empfehlungen und Referenzen für den gesamten Lebenszyklus der Modellentwicklung – etwa für den Umgang mit Trainingsdaten und Modellartefakten. Es richtet sich an Organisationen, die KI-Modelle entwickeln, in Systeme integrieren oder beschaffen, und ist ausdrücklich zur gemeinsamen Nutzung mit SP 800-218 konzipiert.
04OWASP SAMM: Reifegrad messen und eine Roadmap ableiten
Während das SSDF beschreibt, was zu tun ist, beantwortet das OWASP Software Assurance Maturity Model (SAMM, Version 2 seit Januar 2020, aktuell Version 2.2 von Juli 2024), wie gut eine Organisation es bereits tut. Das Modell gliedert sich in fünf Business Functions – Governance, Design, Implementation, Verification und Operations – mit je drei Security Practices (insgesamt 15), die jeweils über zwei Streams und drei Reifegradstufen bewertet werden. SAMM ist explizit als messbares Modell konzipiert und erfasst neben der Abdeckung auch die Qualität der Aktivitäten; aus dem Ergebnis lässt sich eine priorisierte Verbesserungs-Roadmap ableiten. Ein SAMM-Self-Assessment stellt VamiSec unter ssdlc-assessment.com bereit.
05Security Gates: definierte Prüfpunkte je Phase
Security Gates sind vorab definierte Kriterien, die ein Vorhaben erfüllen muss, bevor es in die nächste Phase übergeht – genau das fordert SSDF-Practice PO.4 („Define and Use Criteria for Software Security Checks“). Typische Gates sind: dokumentierte Sicherheitsanforderungen in der Anforderungsphase (PO.1), ein Threat Model im Design (PW.1), Secure-Coding-Vorgaben und automatisierte Prüfungen wie SAST und Software Composition Analysis in der Implementierung (PW.5, PO.3), Code-Reviews und Sicherheitstests vor dem Release (PW.7, PW.8) sowie geschützte Build- und Release-Artefakte mit nachweisbarer Integrität (PS.1, PS.2). Im Betrieb schließen kontinuierliche Schwachstellenidentifikation, Priorisierung und Ursachenanalyse (RV.1–RV.3) den Kreislauf. Wirksame Gate-Kriterien werden messbar formuliert – etwa über den Anteil bestandener Gates, die Zeit bis zur Behebung gefundener Schwachstellen oder das Wiederauftreten gleicher Schwachstellenklassen; SAMM verankert diese Steuerung in der Practice „Strategy & Metrics“.
06CRA: Prozesspflichten für Produkte mit digitalen Elementen
Der Cyber Resilience Act (Verordnung (EU) 2024/2847, in Kraft seit Dezember 2024) macht einen funktionierenden SSDLC für Hersteller von Produkten mit digitalen Elementen zur Pflicht: Anhang I Teil I definiert Anforderungen an die Produkteigenschaften (u. a. Security by Design und sichere Voreinstellungen auf Basis einer Risikobewertung), Teil II Anforderungen an die Behandlung von Schwachstellen – einschließlich der Erstellung einer Software Bill of Materials (SBOM). Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle sind ab dem 11. September 2026 meldepflichtig (Frühwarnung binnen 24 Stunden, weitere Angaben binnen 72 Stunden, Abschlussbericht nach 14 Tagen bzw. einem Monat); vollständig anwendbar ist die Verordnung ab dem 11. Dezember 2027. Sicherheitsupdates müssen über einen Unterstützungszeitraum von in der Regel fünf Jahren bereitgestellt werden – ohne dokumentierte Entwicklungs- und Schwachstellenprozesse ist das kaum belastbar nachweisbar.
