Stephan VossISO (Information Security Officer)stephan.voss@stephan-voss.deLinkedIn
ISMS-GRC-WEBGOVERNANCE · RISK · COMPLIANCE · ASSURANCE
LIFECYCLE

Software Development Life Cycle (SDLC)

Eigene Softwareänderungen über Anforderungen, Entwicklung, Test, Release und Wartung kontrollieren.

LERNHILFE · SECURE SOFTWARE DEVELOPMENT FRAMEWORK

Security begleitet den Entwicklungsweg – sie wird nicht am Ende angeklebt

NIST SP 800-218, das Secure Software Development Framework (SSDF), bündelt grundlegende sichere Entwicklungspraktiken in vier Gruppen. Das Framework kann in unterschiedliche SDLC-Modelle integriert werden.

PREPARE THE ORGANIZATION

Rollen, Anforderungen, Werkzeuge und sichere Arbeitsweise vorbereiten.

PROTECT THE SOFTWARE

Code, Artefakte und Entwicklungsumgebung vor Manipulation schützen.

PRODUCE WELL-SECURED SOFTWARE

Security in Design, Entwicklung, Review und Verifikation einbauen.

RESPOND TO VULNERABILITIES

Schwachstellen nach Release erkennen, behandeln und Ursachen für Wiederholungen adressieren.

Beispiel: Eine kleine Änderung am internen Web-Framework

Vor der Änderung sind Verantwortlichkeit und Anforderungen klar. Der Quellstand bleibt geschützt und versioniert. Die Änderung wird in einer Entwicklungsumgebung geprüft. Nach Release bleiben Findings, Komponenten und spätere Schwachstellen weiter steuerbar.

Abgrenzung: SSDF ist kein bestimmtes Entwicklungsmodell. Es ergänzt vorhandene SDLC-Prozesse um sichere Entwicklungspraktiken.

Vertiefung: NIST SP 800-218 – SSDF Version 1.1. Eine Version 1.2 liegt derzeit nur als Entwurf vor und wird deshalb hier nicht als gültige Endfassung verwendet.

VERSTEHEN

Security beginnt vor dem Code

SDLC bezeichnet den strukturierten Lebenszyklus von Software. Security wird in vorhandene Entwicklungsphasen integriert.

ANWENDEN

Vom Änderungsbedarf zur sicheren Freigabe

01
Requirements

Security Requirements.

02
Design

Architektur/Vertrauensgrenzen (Trust Boundaries).

03
Build

Sichere Implementierung.

04
Verify

Code/Konfiguration/Verhalten.

05
Release & Maintain

Freigabe, Monitoring, Updates.

BEISPIEL AUS DEM ALLTAG

Eine kleine Änderung kann das Risikoprofil verändern

Ein Application Programming Interface (API)-Endpunkt erhält Zugriffsanforderungen, negative Tests und Monitoring.

NACHWEISEN

Was nach dem Release nachvollziehbar bleiben muss

Security RequirementsHält Sicherheitsanforderungen so konkret fest, dass ihre Umsetzung in Design, Entwicklung, Test und Abnahme überprüft werden kann.
Threat ModelZeigt relevante Bedrohungen, Angriffspfade, betroffene Komponenten und vorgesehene Gegenmaßnahmen.
Test EvidenceHält Prüfumfang, Durchführung, Ergebnis und relevante Abweichungen fest.
Release ApprovalBelegt, wer einen konkreten Softwarestand auf Basis welcher Prüfungen für die Bereitstellung freigegeben hat und welche Auflagen gelten.