SSDLC – Secure Software Development Lifecycle

„Security ist kein Feature, das man am Ende draufklebt – sondern ein Mindset, das von Anfang an fehlt."

Sinn & Zweck

SSDLC ist der Versuch, Security nicht als nachträglichen Gedanken zu behandeln, sondern als integralen Bestandteil jeder Entwicklungsphase. Von der ersten Idee bis zum letzten Deployment soll Security mitgedacht werden.

Klingt vernünftig? Ist es auch. Wird trotzdem selten gemacht.

Der klassische SDLC (Software Development Lifecycle) kümmert sich um:

Requirements → Design → Entwicklung → Testing → Deployment → Wartung

SSDLC fügt bei jedem Schritt die Security-Perspektive hinzu:

Security Requirements → Threat Modeling → Secure Coding → Security Testing → Secure Deployment → Monitoring & Response

Die Phasen

1. Requirements & Planning

Security Questions:

Welche Daten verarbeitet die Anwendung?
Wer sind potenzielle Angreifer?
Welche Compliance-Anforderungen gibt es?
Was ist der Schutzbedarf (Vertraulichkeit, Integrität, Verfügbarkeit)?

Output:

Security Requirements
Initiales Risiko-Assessment
Compliance-Checkliste

2. Design & Architecture

Aktivitäten:

Threat Modeling – Wer will uns was antun?
Security Architecture Review – Ist das Design sicher?
Data Flow Diagrams – Wo fließen sensitive Daten?

Security Design Principles:

✓ Principle of Least Privilege
✓ Defense in Depth
✓ Fail Secure
✓ Separation of Concerns
✓ Don't Trust Input
✓ Don't Roll Your Own Crypto

3. Development

Secure Coding Practices:

Input Validation (alles ist böse, bis das Gegenteil bewiesen ist)
Output Encoding (XSS-Prävention)
Parameterized Queries (SQL Injection, begone!)
Secure Session Management
Proper Error Handling (keine Stack Traces an User)

Tools & Automation:

IDE-Plugins (SonarLint, Snyk, etc.)
Pre-commit Hooks für Secret-Scanning
Peer Reviews mit Security-Fokus

4. Testing

Security Testing Types:

Test	Phase	Automatisiert?
SAST	Build	Ja
DAST	Deploy	Ja
IAST	QA	Ja
SCA	Build	Ja
Penetration Test	Pre-Release	Nein
Security Review	Pre-Release	Nein

5. Deployment

Secure Deployment Checklist:

Secrets in Vault, nicht in Code
TLS überall
Security Headers gesetzt
Debug-Modi deaktiviert
Least-Privilege für Service Accounts
Logging aktiviert (aber keine sensitiven Daten!)

6. Operations & Maintenance

Ongoing Security:

Vulnerability Management
Patch Management
Security Monitoring (SIEM)
Incident Response
Regelmäßige Security Reviews

Frameworks & Standards

Microsoft SDL

Das Ur-SSDLC-Framework, entwickelt nach den Schmerzen von Code Red, Nimda und Blaster.

Phasen:

Training
Requirements
Design
Implementation
Verification
Release
Response

OWASP SAMM (Software Assurance Maturity Model)

Hilft, den Security-Reifegrad zu messen und zu verbessern.

Business Functions:

Governance
Design
Implementation
Verification
Operations

Maturity Levels: 1-3 pro Bereich

BSIMM (Building Security In Maturity Model)

Deskriptiv statt präskriptiv – misst, was andere Firmen machen.

NIST SSDF (Secure Software Development Framework)

US-Regierungsstandard, zunehmend auch für Zulieferer relevant.

Methoden & Implementierung

Security Gate Model

                    [Gate 1]         [Gate 2]         [Gate 3]
Requirements ──────────┼─── Design ──────┼─── Code ──────┼─── Release
                       │                 │                │
                  Threat Model      SAST Pass        Pentest Done
                  Risk Assessment   Code Review      DAST Clean
                                   SCA Clean        Sign-Off

Agile/DevSecOps Integration

Sprint Planning:

Security Stories einplanen
Threat Models updaten

Daily:

SAST in IDE
Automated Security Tests

Sprint Review:

Security Metrics reviewen
Technical Debt tracken

Retrospective:

Security Incidents besprechen
Prozesse verbessern

Beispiel: User Story mit Security

Als User möchte ich mich einloggen können.

Acceptance Criteria:
- [ ] Login mit Username/Password
- [ ] Session-Timeout nach 30 Minuten

Security Criteria:
- [ ] Password wird bcrypt-gehasht (cost=12)
- [ ] Rate Limiting: 5 Versuche, dann 5 Min Sperre
- [ ] Session-Token: 256-bit, HttpOnly, Secure, SameSite=Strict
- [ ] Audit-Log bei Login/Logout/Failed Attempts
- [ ] MFA-Option verfügbar

Risiken & Grenzen

"Wir haben keine Zeit für Security"

Der Klassiker. Deadline drückt, Security wird gestrichen. Das rächt sich später, wenn der Breach teurer ist als jede Verzögerung.

Security Theater

Manager: "Wir machen SSDLC!"
Reality: Eine Checkliste, die niemand liest, und ein Tool, das ignoriert wird.

Tool-Überflutung

SAST-Tool A
DAST-Tool B
SCA-Tool C
Container-Scanner D
Secret-Scanner E

Ergebnis: 5 Dashboards, die niemand anschaut.

Security vs. Velocity

CISO: "Kein Deploy ohne vollständigen Security Review!"
Devs: "Aber wir deployen 50x am Tag!"
CISO: "..."

Skills-Gap

Entwickler sind keine Security-Experten. Security-Experten verstehen oft keinen Code. Die Brücke zu bauen ist die eigentliche Herausforderung.

Legacy-Systeme

SSDLC für neue Projekte? Easy. SSDLC für das 20 Jahre alte COBOL-System, das niemand mehr versteht? Viel Glück.

Vorteile

Kosten-Shift

Bug in Requirements: 1x Kosten
Bug in Design: 5x Kosten
Bug in Coding: 10x Kosten
Bug in Testing: 20x Kosten
Bug in Production: 100x Kosten
Bug nach Breach: ∞ Kosten

Weniger Security Debt

Kontinuierliche Security-Arbeit verhindert, dass sich Probleme aufstauen.

Compliance by Design

GDPR, PCI-DSS, HIPAA – wenn Security von Anfang an dabei ist, sind die Audits weniger schmerzhaft.

Bessere Dokumentation

Threat Models, Risk Assessments, Security Reviews – alles dokumentiert, alles nachvollziehbar.

Security-Awareness

Entwickler lernen durch SSDLC kontinuierlich dazu. Der Nebeneffekt: Besserer Code von Anfang an.

Best Practices

Klein anfangen – Nicht alles auf einmal implementieren, sondern schrittweise
Champions etablieren – Security-interessierte Entwickler als Multiplikatoren
Automatisieren – Was automatisiert werden kann, wird auch gemacht
Feedback-Loops verkürzen – Entwickler müssen schnell erfahren, wenn etwas unsicher ist
Security als Enabler positionieren – Nicht als Blocker, sondern als Unterstützung
Metriken tracken:
- Mean Time to Remediate
- Vulnerabilities per Release
- Security Coverage
- Training Completion
Executive Buy-In sichern – Ohne Management-Support stirbt jede Initiative

Reifegradmodell (Vereinfacht)

Level	Beschreibung	Typische Aktivitäten
1 – Ad-hoc	Kein systematischer Ansatz	Gelegentliche Scans, wenn jemand dran denkt
2 – Basic	Grundlegende Prozesse	SAST in CI/CD, jährlicher Pentest
3 – Managed	Definierte Prozesse	Threat Modeling, Security Gates
4 – Proactive	Proaktive Security	Security Champions, Metrics, Continuous Improvement
5 – Optimizing	Kontinuierliche Optimierung	Risk-based Prioritization, Predictive Analysis

Fazit

SSDLC ist kein Produkt, das man kauft, und kein Tool, das man installiert. Es ist ein Kulturwandel, der Security in jeden Aspekt der Softwareentwicklung integriert.

Der schwierigste Teil ist nicht die Technik – sondern die Menschen dazu zu bringen, Security als Teil ihrer Arbeit zu sehen, nicht als Hindernis.

"Secure by Design" klingt toll auf Folien. In der Realität bedeutet es: Jeden Tag aufs Neue kämpfen.

Weiterführende Ressourcen: