Secure SDLC & Cyber Resilience Act – Der vollständige Leitfaden

Sicherheit ist kein Feature – sie ist ein Prozess

Softwareentwicklung war lange Zeit eine Disziplin, in der Sicherheit am Ende dazukam: erst liefern, dann härten. Diese Ära ist vorbei – aus zwei Richtungen gleichzeitig.

Zum einen hat die Praxis gezeigt, dass nachträgliche Sicherheit teuer, fehleranfällig und unvollständig ist. Zum anderen hat die EU mit dem Cyber Resilience Act (CRA) genau dieses Prinzip zum Gesetz gemacht: Sicherheit muss von Anfang an Teil der Entwicklung sein, nachweisbar und über den gesamten Produktlebenszyklus aufrechterhalten werden.

Dieser Beitrag zeigt, wie ein Secure Software Development Lifecycle (Secure SDLC) strukturiert ist, welche Tools in jeder Phase eingesetzt werden – und wo die CRA-Anforderungen konkret anknüpfen.

⚠️ Wichtig: Ab dem 11. September 2026 gelten die ersten CRA-Meldepflichten. Hersteller müssen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden ab Kenntnis bei ENISA melden. Das ist in drei Monaten.

Was ist der Secure SDLC?

Der klassische Software Development Lifecycle beschreibt die Phasen, die Software von der Idee bis zum Betrieb durchläuft: Design, Entwicklung, Test, Deployment und Betrieb. Der Secure SDLC erweitert jede dieser Phasen um konkrete Sicherheitsmaßnahmen.

Das zentrale Prinzip heißt Shift Left: Sicherheit so früh wie möglich in den Prozess integrieren. Ein Fehler der im Design-Stadium gefunden wird, kostet einen Bruchteil dessen, was eine Schwachstelle in der Produktion verursacht.

💡 Shift Left in Zahlen: Eine Schwachstelle die in der Design-Phase gefunden wird, kostet im Schnitt 80× weniger zu beheben als dieselbe Schwachstelle nach dem Release.

Der Secure SDLC besteht aus sieben Phasen – jede mit eigenem Fokus, eigenen Tools und eigenen CRA-Anforderungen:

• 🗺️ Design → Threat Modeling, CRA Risk Assessment
• 🔍 Code → SAST, Secrets Detection
• 📦 Build → SCA, SBOM
• 🏗️ Infrastruktur → IaC-Scanning
• 🧪 Test → DAST
• 🛡️ Produktion → Runtime Security
• 📋 Monitoring → Vulnerability Management

Phase 1: Design & Planung – Threat Modeling

In der Design-Phase wird die Architektur eines Systems festgelegt. Threat Modeling und eine strukturierte CRA-Gap-Analyse stellen sicher, dass Angriffsflächen und Compliance-Lücken bereits beim Entwurf identifiziert werden – bevor teure Nacharbeit entsteht.

Tool: COMPLYD (complyd.io)

SaaS-Plattform für CRA-Compliance und Threat Modeling – entwickelt damit Hersteller die CRA-Anforderungen ohne tiefes Expertenwissen strukturiert umsetzen können.

• Risikomodell & Threat Modeling: Geführte Risikomodellierung mit gezielten Fragen – identifiziert Lücken und Risiken in der Produktarchitektur direkt im Tool.
• CRA-Anforderungen als Workflow: Alle Annex-I-Anforderungen sind hinterlegt – mit KI-gestützten Hilfestellungen und konkreten Beispielen.
• Automatische Dokumentengenerierung: Konformitätsnachweise, technische Dokumentation und normkonformes User Manual direkt aus der Plattform.
• Meldeprozesse ready-to-use: Vorgefertigte Workflows für Incident- und Vulnerability-Meldungen – sofort bereit für die ENISA-Meldepflicht ab September 2026.

⚖️ CRA-Anforderung – Annex I & Article 14: Der CRA verlangt explizit Secure by Design: Risikobewertungen müssen vor der Entwicklung durchgeführt und dokumentiert werden. COMPLYD bildet genau diesen Prozess ab – inklusive automatisch generierter, auditfester Dokumentation.

Phase 2: Secure Coding – SAST & Secrets Detection

SAST-Tools analysieren den Quellcode statisch – ohne ihn auszuführen. Secrets-Detection verhindert, dass API-Keys und Passwörter ins Repository gelangen.

Tools (Open Source)

• Semgrep: Statische Code-Analyse für 30+ Sprachen mit 3.000+ Community-Regeln. Findet SQL Injection, XSS, unsichere Kryptographie und mehr.
• SonarQube CE: Quality Gates mit Security-Regeln und direktem Mapping auf CRA Annex I Anforderungen.
• Gitleaks: Scannt den gesamten Git-Verlauf auf API-Keys, Passwörter, Tokens und Zertifikate – auch in alter History.

⚖️ CRA-Anforderung – Annex I Part I: Hersteller müssen nachweisen, dass Produkte keine bekannten ausnutzbaren Schwachstellen enthalten. SAST ist der direkte Mechanismus um diesen Nachweis automatisch und wiederholbar zu erbringen.

Phase 3: Build & Abhängigkeiten – SCA & SBOM

Moderne Software besteht zu 80–90% aus Drittanbieter-Bibliotheken. SCA prüft diese auf bekannte CVEs. SBOM dokumentiert alle Komponenten maschinenlesbar – und ist ab Dezember 2027 verpflichtend.

Tools (Open Source)

• Syft: Generiert SBOMs aus Container-Images in den Formaten CycloneDX und SPDX – der CRA-konforme Standard.
• Grype: CVE-Matching gegen SBOMs. Bricht CI/CD-Builds ab wenn kritische Schwachstellen gefunden werden.
• Dependency-Track: Kontinuierliches SBOM-Monitoring – alarmiert automatisch wenn neue CVEs für bekannte Komponenten auftauchen.

⚖️ CRA-Anforderung – SBOM & Lieferkette: Der CRA macht SBOM zur Pflicht. Ab Dezember 2027 ist SBOM-basiertes Vulnerability-Monitoring Voraussetzung für die Meldepflicht nach Article 14.

Phase 4: Infrastruktur – IaC-Scanning

Infrastructure as Code (Terraform, Kubernetes, Dockerfile) wird statisch auf Fehlkonfigurationen geprüft – bevor sie deployed werden. Offene S3-Buckets, fehlende Verschlüsselung, Container die als root laufen.

Tools (Open Source)

• Checkov: Universeller IaC-Scanner für Terraform, CloudFormation, Kubernetes und Dockerfile. Exit-Code 1 bei Fail blockiert den Build.
• tfsec: Terraform-spezialisierter Scanner mit sehr niedrigem False-Positive-Rate.
• Kubesec: Security-Score für Kubernetes-Manifeste. Findet privilegierte Container und unsichere Capabilities.

⚖️ CRA-Anforderung – Secure by Default: Der CRA verlangt dass Produkte in einer sicheren Standardkonfiguration ausgeliefert werden. IaC-Scanning stellt sicher, dass keine unsicheren Defaults in die Infrastruktur gelangen.

Phase 5: Dynamisches Testen – DAST

DAST testet die laufende Anwendung von außen – wie ein echter Angreifer. Es schickt echte Angriffs-Payloads und beobachtet die Reaktion. Wichtig: Immer nur gegen Testumgebungen, niemals gegen Produktion!

Tools (Open Source)

• OWASP ZAP: Der Standard im Open-Source-DAST. Version 5.3 (2026) mit neuem AJAX Spider für Single Page Applications und DOM-XSS-Detection.
• Nuclei: Template-basierter Scanner. Neue Templates für neue CVEs erscheinen oft innerhalb von Stunden nach öffentlicher Bekanntmachung.

Phase 6: Runtime Security – Was passiert in Produktion?

Runtime Security überwacht laufende Container auf Kernel-Ebene. Es ist das Einbruchmeldesystem – und geht davon aus, dass ein Angreifer es irgendwann durch alle anderen Schichten schafft.

Tools (Open Source)

• Falco: De-facto-Standard. Überwacht Systemaufrufe und alarmiert bei Shell-Spawning, unerwarteten Netzwerkverbindungen und sensiblen Dateizugriffen.
• Tetragon: eBPF-basiert mit Kernel-Level-Enforcement – kann Prozesse direkt beenden bevor eine Aktion abgeschlossen ist.
• Kyverno: Policy-as-Code für Kubernetes. Verhindert das Deployen unsicherer Konfigurationen.

⚖️ CRA-Anforderung – Incident Meldepflicht

Phase 7: Vulnerability Management – Dauerhaft über den Lebenszyklus

Der Secure SDLC endet nicht mit dem Deployment. Neue CVEs für bekannte Komponenten müssen erkannt, bewertet und behoben werden – über den gesamten Support-Zeitraum des Produkts.

Tools (Open Source)

• Dependency-Track: SBOM-basiertes Continuous Monitoring. Alarmiert automatisch sobald neue CVEs für verbaute Komponenten bekannt werden.
• OpenVEX / CSAF: Maschinenlesbare Vulnerability-Advisories für strukturierte Kommunikation an Kunden und Behörden.

⚖️ CRA-Anforderung – Article 14: Ab September 2026: Meldung innerhalb von 24h an ENISA, vollständiger Report in 72h, Abschlussbericht in 14 Tagen.

CRA-Anforderungen im Überblick: Mapping zu SDLC-Phasen

CRA-Fristen im Überblick

• ✅ 10. Dezember 2024 – CRA tritt in Kraft. Die Uhr läuft.
• ✅ 11. Juni 2026 – Konformitätsbewertungsstellen notifiziert. CE-Kennzeichnung kann ab jetzt vorbereitet werden.
• ⚠️ 11. September 2026 (in 3 Monaten!) – Meldepflichten starten: 24h Frühwarnung an ENISA, 72h vollständiger Report, 14 Tage Abschlussbericht.
• 🔵 11. Dezember 2027 – Vollständige CRA-Compliance Pflicht. Jedes neue Produkt am EU-Markt muss compliant sein, inklusive CE-Kennzeichnung.

Fazit: Secure SDLC ist der technische Umsetzungsrahmen des CRA

Der CRA definiert was erreicht werden muss. Der Secure SDLC mit seinen Tools definiert wie es erreicht wird. Wer heute einen strukturierten, toolgestützten Secure SDLC betreibt, ist zu einem großen Teil bereits CRA-compliant.

Der entscheidende Vorteil: Anders als ein einmaliges Sicherheitsaudit ist der Secure SDLC ein kontinuierlicher Prozess. Jeder neue Commit wird geprüft, jede neue Dependency überwacht, jeder Vorfall erkannt und gemeldet – automatisch, nachweisbar, skalierbar.

✅ Handlungsempfehlung für die nächsten 90 Tage: Dependency-Track für SBOM-Monitoring aufsetzen, Falco für Runtime-Detection deployen und Incident-Response-Prozess für die ENISA-Meldepflicht dokumentieren. Für strukturierte CRA-Compliance ohne Expertenwissen: complyd.io