Von Prinzipien zu Prozessen
Ein Softwareteam bei einem Hersteller von Industriesteuerungen steht vor einer typischen Situation: Das nächste Release ist in sechs Wochen geplant, aber die neue CRA-Compliance-Anforderung wurde gerade erst kommuniziert. Der Projektleiter fragt: Können wir die Sicherheitsprüfungen am Ende des Sprints nachholen? Die Antwort ist ernüchternd: Sicherheit lässt sich nicht wie ein Feature am Ende anhängen. Sie muss von Anfang an in den Entwicklungsprozess integriert sein.
Zur Einordnung: Der Cyber Resilience Act (Verordnung 2024/2847) ist die erste EU-weite Regulierung, die Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen verbindlich vorschreibt. Die Verordnung trat am 10. Dezember 2024 in Kraft und wird ab dem 11. Dezember 2027 vollständig angewendet. Anhang I definiert die technischen Anforderungen an die Produktsicherheit, die in der Entwicklung umgesetzt werden müssen.
Die Security-by-Design-Prinzipien aus dem vorherigen Teil sind konzeptionell klar. Die Herausforderung liegt in der praktischen Umsetzung im Entwicklungsalltag. Der Secure Development Lifecycle (SDLC) bietet einen systematischen Rahmen, der Sicherheitsaktivitäten in jede Phase der Produktentwicklung einbettet. Der CRA fordert keine bestimmte Entwicklungsmethodik. Er fordert Ergebnisse: sichere Produkte, dokumentierte Prozesse, nachvollziehbare Entscheidungen. Die hier beschriebenen Praktiken sind bewährt und lassen sich in verschiedene Entwicklungsmodelle integrieren, ob Wasserfall, agil oder DevOps.
Dieser Artikel behandelt die praktische Integration von Sicherheit in den Entwicklungsprozess: von der Anforderungsanalyse über Threat Modeling und sichere Codierung bis hin zu automatisierten Tests in CI/CD-Pipelines. Der Fokus liegt auf pragmatischen Ansätzen, die auch in ressourcenbeschränkten Umgebungen umsetzbar sind. Die hier beschriebenen Entwicklungspraktiken bilden das erste Element des CRA-Operating-Models: Entwicklung schafft die Grundlage, auf der Betrieb (Teil 4) und Nachweis (Teil 5) aufbauen.
Der Secure Development Lifecycle
Ein Secure Development Lifecycle integriert Sicherheitsaktivitäten in alle Phasen der Softwareentwicklung: Anforderungsanalyse, Design, Implementierung, Test, Release und Wartung. Der Grundgedanke ist empirisch belegt: Je früher Sicherheitsprobleme erkannt werden, desto günstiger ist ihre Behebung. Eine Schwachstelle, die im Design gefunden wird, kostet einen Bruchteil dessen, was ihre Behebung nach dem Release kosten würde.
Microsoft hat den Begriff SDL (Security Development Lifecycle) geprägt und seit 2004 für alle Produkte verbindlich gemacht. Die Erfahrungen zeigen: Nach Einführung des SDL sank die Anzahl der Sicherheitslücken in Microsoft-Produkten signifikant. Andere Frameworks wie OWASP SAMM (Software Assurance Maturity Model) oder BSIMM (Building Security In Maturity Model) bieten ähnliche Strukturen mit unterschiedlichen Schwerpunkten. Der CRA schreibt kein bestimmtes Framework vor, aber die Anforderungen in Anhang I lassen sich mit jedem dieser Ansätze erfüllen.
Was gehört in die Sicherheitsanforderungen?
Am Anfang steht die Definition von Sicherheitsanforderungen. Diese ergeben sich aus mehreren Quellen: den CRA-Anforderungen in Anhang I, den spezifischen Risiken des Produkts, branchenspezifischen Standards und den Erwartungen der Nutzer. Sicherheitsanforderungen sollten genauso dokumentiert und priorisiert werden wie funktionale Anforderungen. Sie sind keine Nebensache, sondern integraler Bestandteil der Produktspezifikation.
Konkrete Beispiele für Sicherheitsanforderungen eines IoT-Geräts: Alle Kommunikation muss TLS 1.2 oder höher verwenden. Passwörter müssen bei Ersteinrichtung geändert werden. Firmware-Updates müssen signiert sein. Das Gerät muss fehlgeschlagene Anmeldeversuche protokollieren. Diese Anforderungen sind testbar und verifizierbar. Vage Formulierungen wie das System soll sicher sein sind nicht umsetzbar und sollten vermieden werden.
Risikobewertung nach CRA
Der CRA fordert in Artikel 13 Absatz 2 eine Cybersicherheits-Risikobewertung vor Inverkehrbringen. Diese Bewertung identifiziert potenzielle Bedrohungen, bewertet ihre Eintrittswahrscheinlichkeit und mögliche Auswirkungen. Daraus ergeben sich die erforderlichen Schutzmaßnahmen. Die Risikobewertung muss dokumentiert werden und ist Teil der technischen Dokumentation.
Die Risikobewertung ist keine einmalige Aktivität. Sie muss bei wesentlichen Änderungen am Produkt aktualisiert werden. Neue Funktionen, geänderte Architektur oder neu bekannt gewordene Bedrohungen können eine Neubewertung erforderlich machen. In agilen Umgebungen empfiehlt sich eine regelmäßige Überprüfung, etwa quartalsweise oder bei jedem Major Release.
Threat Modeling in der Praxis
Threat Modeling ist eine strukturierte Methode, um Bedrohungen für ein System zu identifizieren, bevor sie zu Schwachstellen werden. Die Methode beantwortet vier zentrale Fragen: Was bauen wir? Was kann schiefgehen? Was tun wir dagegen? Haben wir es richtig gemacht? Das Ergebnis ist eine dokumentierte Liste identifizierter Bedrohungen und der Maßnahmen zu ihrer Mitigierung.
Threat Modeling ist besonders wertvoll in der frühen Designphase, wenn Architekturentscheidungen noch offen sind. Eine Bedrohung, die im Design erkannt wird, kann durch Architekturänderungen adressiert werden. Dieselbe Bedrohung nach der Implementierung zu beheben erfordert oft aufwändige Umbauten. Die Investition in frühes Threat Modeling zahlt sich mehrfach aus.
STRIDE als Rahmenwerk
STRIDE ist ein weit verbreitetes Rahmenwerk für Threat Modeling, entwickelt von Microsoft. Das Akronym steht für sechs Bedrohungskategorien: Spoofing (Identitätsvortäuschung) betrifft die Authentifizierung. Tampering (Manipulation) betrifft die Integrität von Daten. Repudiation (Abstreitbarkeit) betrifft die Nachvollziehbarkeit von Aktionen. Information Disclosure (Informationspreisgabe) betrifft die Vertraulichkeit. Denial of Service (Dienstverweigerung) betrifft die Verfügbarkeit. Elevation of Privilege (Rechteausweitung) betrifft die Autorisierung.
Für jede Komponente und jeden Datenfluss im System wird geprüft, welche dieser sechs Bedrohungskategorien relevant sind. STRIDE ist systematisch und vollständig, kann aber bei komplexen Systemen aufwändig werden. Alternative Frameworks wie PASTA (Process for Attack Simulation and Threat Analysis) oder Attack Trees bieten andere Perspektiven und können je nach Kontext besser geeignet sein.
Praktisches Beispiel: Smart-Home-Gateway
Ein Smart-Home-Gateway verbindet lokale Geräte (Sensoren, Aktoren) mit einer Cloud-Plattform und einer mobilen App. Das Threat Model beginnt mit einem Datenflussdiagramm: Sensordaten fließen zum Gateway, werden dort verarbeitet und an die Cloud gesendet. Die App kommuniziert mit der Cloud und kann Befehle an das Gateway senden. Vertrauensgrenzen existieren zwischen lokalem Netzwerk, Gateway, Cloud und App.
Die STRIDE-Analyse für den Datenfluss Gateway-zu-Cloud ergibt: Spoofing: Kann sich ein Angreifer als Gateway ausgeben? Maßnahme: Gegenseitige TLS-Authentifizierung mit Zertifikaten. Tampering: Können Daten auf dem Transportweg manipuliert werden? Maßnahme: TLS-Verschlüsselung. Information Disclosure: Können Daten abgefangen werden? Maßnahme: TLS-Verschlüsselung, Certificate Pinning. Denial of Service: Kann die Verbindung blockiert werden? Maßnahme: Offline-Funktionalität, Reconnect-Logik. Diese Analyse wird für jeden kritischen Datenfluss durchgeführt.
Tools und Integration
Microsoft Threat Modeling Tool und OWASP Threat Dragon sind kostenlose Tools, die den Prozess unterstützen. Sie ermöglichen das Zeichnen von Datenflussdiagrammen und generieren automatisch Bedrohungslisten basierend auf STRIDE. Die Ergebnisse können exportiert und in Issue-Tracker wie Jira überführt werden. In agilen Umgebungen kann Threat Modeling iterativ erfolgen: ein initiales Modell zu Beginn des Projekts, Aktualisierungen bei signifikanten Architekturänderungen.
Sichere Code-Praktiken
Guter Code ist lesbarer Code. Sicherer Code ist Code, der bekannte Schwachstellenmuster vermeidet. Die meisten Sicherheitslücken in Software fallen in wiederkehrende Kategorien: Injection-Angriffe, Buffer Overflows, unsichere Deserialisierung, fehlerhafte Authentifizierung. Sichere Codierrichtlinien helfen Entwicklern, diese Fehler systematisch zu vermeiden.
OWASP Top 10 und CWE
Die OWASP Top 10 listen die häufigsten Sicherheitsrisiken für Webanwendungen. Die aktuelle Version (2025) umfasst: Broken Access Control, Security Misconfiguration, Software Supply Chain Failures (erweitert aus Vulnerable Components), Cryptographic Failures, Injection, Insecure Design, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Alerting Failures, sowie neu Mishandling of Exceptional Conditions. Für Embedded-Systeme und IoT existieren spezifische Listen wie die OWASP IoT Top 10.
Die Common Weakness Enumeration (CWE) ist eine umfassendere Katalogisierung von Schwachstellentypen. Die CWE Top 25 (aktuell Version 2025) listet die gefährlichsten Software-Schwachstellen, basierend auf der Analyse von über 39.000 CVEs. Viele SAST-Tools referenzieren CWE-IDs in ihren Findings. Die Kenntnis dieser Kategorien hilft Entwicklern, Schwachstellen zu verstehen und zu vermeiden. Schulungen sollten diese Grundlagen vermitteln.
Verbindliche Codierrichtlinien
Sichere Codierrichtlinien definieren verbindliche Regeln für das Entwicklungsteam. Sie sollten spezifisch für die verwendeten Programmiersprachen und Frameworks sein. Allgemeine Prinzipien umfassen: Alle externen Eingaben validieren, bevor sie verarbeitet werden. Parameterisierte Abfragen statt String-Konkatenation für Datenbankzugriffe. Kryptografische Standardbibliotheken verwenden, keine eigene Kryptografie implementieren. Keine hartkodierten Credentials oder API-Keys im Quellcode.
Für C/C++ sind die CERT C Coding Standards und MISRA C:2025 etablierte Regelwerke. MISRA C:2025 enthält 225 aktive Richtlinien und unterstützt C90 bis C18. Für Java bieten die CERT Oracle Coding Standards Orientierung. Diese Richtlinien sollten in Code Reviews geprüft und durch statische Analyse automatisiert werden. Die Einführung von Codierrichtlinien erfordert Schulung und eine Übergangsphase. Bestehender Code muss nicht sofort konform sein, aber neuer Code sollte die Regeln einhalten.
Wie managt man Abhängigkeiten sicher?
Moderne Software besteht zu einem erheblichen Teil aus Drittanbietercode. Studien zeigen, dass typische Anwendungen zu 70-90 Prozent aus Open-Source-Komponenten bestehen. Diese Abhängigkeiten können Schwachstellen enthalten. Der Log4Shell-Vorfall demonstrierte die Tragweite: Eine Schwachstelle in einer weit verbreiteten Logging-Bibliothek betraf Millionen von Systemen.
Systematisches Abhängigkeitsmanagement umfasst: Ein vollständiges Inventory aller Abhängigkeiten (SBOM), regelmäßige Prüfung gegen Schwachstellendatenbanken, zeitnahe Updates bei Sicherheitspatches, Evaluierung neuer Abhängigkeiten vor der Einführung. Tools wie Dependabot, Renovate oder Snyk automatisieren die Überwachung und können Pull Requests für Updates automatisch erstellen. Die Integration in CI/CD-Pipelines stellt sicher, dass keine bekannt verwundbaren Komponenten in Produktion gelangen.
Security Testing
Der CRA verlangt in Anhang I, dass Produkte vor Inverkehrbringen auf Schwachstellen geprüft werden. Security Testing umfasst verschiedene Methoden, die sich ergänzen. Keine einzelne Methode findet alle Schwachstellen. Eine Kombination aus statischer Analyse, dynamischen Tests und manuellen Reviews ist erforderlich.
Static Application Security Testing (SAST)
SAST-Tools analysieren Quellcode oder kompilierten Code, ohne ihn auszuführen. Sie erkennen Muster, die auf Schwachstellen hindeuten: unvalidierte Eingaben, die in SQL-Abfragen fließen (SQL Injection), unsichere Funktionsaufrufe (Buffer Overflow), hardkodierte Secrets. SAST kann früh im Entwicklungsprozess eingesetzt werden, idealerweise bei jedem Commit. Die Integration in IDEs ermöglicht Echtzeit-Feedback während des Codierens.
Bekannte SAST-Tools sind SonarQube (Open Source, breite Sprachunterstützung), Semgrep (regelbasiert, erweiterbar), CodeQL (GitHub, tiefe semantische Analyse) und kommerzielle Lösungen wie Checkmarx oder Fortify. SAST-Tools produzieren typischerweise viele False Positives. Ein Tuning-Prozess und Suppressions-Management sind erforderlich, um die Entwicklerproduktivität nicht zu beeinträchtigen.
Dynamic Application Security Testing (DAST)
DAST-Tools testen laufende Anwendungen von außen. Sie simulieren Angriffe und prüfen, wie die Anwendung reagiert. DAST findet Schwachstellen, die erst zur Laufzeit auftreten: fehlerhafte Konfigurationen, fehlende Security Header, Authentifizierungs-probleme, Cross-Site-Scripting. DAST erfordert eine lauffähige Umgebung und wird typischerweise gegen Staging-Systeme eingesetzt.
ZAP (Zed Attack Proxy, seit 2024 als ZAP by Checkmarx weitergeführt) ist das bekannteste Open-Source-DAST-Tool. Burp Suite Professional ist im kommerziellen Bereich Standard. Nuclei ermöglicht Template-basierte Scans für spezifische Schwachstellen. DAST-Scans sollten bei jedem Deployment in Testumgebungen automatisiert laufen. Für APIs existieren spezialisierte Tools wie OWASP API Security Testing.
Software Composition Analysis (SCA)
SCA-Tools identifizieren verwendete Open-Source-Komponenten und prüfen sie gegen Schwachstellendatenbanken wie die National Vulnerability Database (NVD), GitHub Advisory Database oder OSV. Sie sind essentiell für das SBOM-Management und die CRA-Compliance. Bei neuen Schwachstellen in Abhängigkeiten alarmieren sie automatisch.
Snyk, Grype, OWASP Dependency-Check und Trivy sind verbreitete Werkzeuge. Sie unterscheiden sich in Genauigkeit, Geschwindigkeit und unterstützten Ökosystemen. Die Integration in CI/CD-Pipelines ist Standard. Policies können definieren, welche Schweregrade einen Build blockieren. CVSS-Score 9+ könnte den Build stoppen, während niedrigere Scores als Warnungen behandelt werden.
Penetrationstests
Penetrationstests (Pentests) simulieren reale Angriffe durch erfahrene Sicherheitsexperten. Sie finden Schwachstellen, die automatisierte Tools übersehen: logische Fehler, komplexe Angriffsketten, Schwachstellen in der Geschäftslogik. Pentests sind aufwändiger und teurer als automatisierte Tests, aber für kritische Produkte unerlässlich.
Der CRA erwähnt Penetrationstests nicht explizit, aber für wichtige Produkte (Important Class I und II gemäß Anhang III) und kritische Produkte (gemäß Anhang IV) sind sie faktisch erforderlich, um die geforderte Sorgfalt nachzuweisen. Pentests sollten vor größeren Releases und regelmäßig (mindestens jährlich) durchgeführt werden. Der Scope sollte klar definiert sein: Black-Box, Grey-Box oder White-Box, welche Systeme, welche Angriffsvektoren.
CI/CD-Integration und DevSecOps
Continuous Integration und Continuous Deployment (CI/CD) ermöglichen schnelle Releasezyklen. Security Testing muss in diese Pipelines integriert werden, ohne sie zu blockieren. Das Konzept nennt sich DevSecOps: Security als integraler Bestandteil des DevOps-Prozesses, nicht als nachgelagerter Gatekeeper. Das Ziel ist Shift Left: Sicherheitsprüfungen so früh wie möglich im Entwicklungsprozess.
Security Gates und Quality Gates
Security Gates sind Prüfpunkte in der Pipeline. Sie definieren Kriterien, die erfüllt sein müssen, bevor Code die nächste Stufe erreicht. Typische Kriterien: Keine kritischen SAST-Findings (CVSS 9+). Alle Abhängigkeiten ohne bekannte CVEs oberhalb eines Schwellenwerts. Alle Security-Unit-Tests bestanden. SBOM erfolgreich generiert. Diese Gates verhindern, dass unsicherer Code in Produktion gelangt.
Die Balance zwischen Sicherheit und Entwicklerproduktivität ist entscheidend. Zu strenge Gates führen zu Frustration und Workarounds. Zu lockere Gates verfehlen ihren Zweck. Ein gestufter Ansatz ist sinnvoll: Kritische Findings blockieren den Build, hohe Findings verhindern das Deployment in Produktion, mittlere und niedrige Findings werden als Technical Debt getrackt und priorisiert bearbeitet.
Automatisierung der Security-Tools
Automatisierung ist der Schlüssel zu skalierbarer Sicherheit. SAST sollte bei jedem Commit oder Pull Request laufen, mit Ergebnissen als Inline-Kommentare im Code Review. SCA läuft kontinuierlich und alarmiert bei neuen Schwachstellen in Abhängigkeiten. DAST läuft bei jedem Deployment in Testumgebungen. SBOM-Generierung ist Teil des Release-Prozesses. Alle Ergebnisse fließen in ein zentrales Dashboard für Visibility und Reporting.
Vulnerability Management
Gefundene Schwachstellen müssen systematisch behandelt werden. Ein Vulnerability-Management-Prozess umfasst mehrere Schritte: Triage prüft, ob es sich um ein echtes Problem handelt oder ein False Positive. Priorisierung bewertet die Kritikalität im Kontext des Produkts. Zuweisung ordnet das Finding einem Verantwortlichen zu. Behebung implementiert den Fix. Verifikation stellt sicher, dass das Problem gelöst ist.
Tools wie DefectDojo, OWASP Dependency-Track oder kommerzielle Application Security Posture Management (ASPM) Plattformen unterstützen diesen Prozess. Sie aggregieren Findings aus verschiedenen Quellen, deduplizieren, priorisieren und tracken den Behebungsfortschritt. SLA-basierte Vorgaben definieren, wie schnell Schwachstellen verschiedener Schweregrade behoben werden müssen.
Dokumentation für CRA-Compliance
Der CRA fordert in Artikel 31 technische Dokumentation. Diese muss den Marktüberwachungsbehörden auf Anfrage zur Verfügung gestellt werden und zehn Jahre nach Inverkehrbringen aufbewahrt werden. Die Dokumentation ist Pflicht und zugleich hilfreich: Sie macht Sicherheitsentscheidungen nachvollziehbar, erleichtert die Wartung und unterstützt bei Audits.
Inhalte der technischen Dokumentation
Anhang VII des CRA definiert die Mindestinhalte der technischen Dokumentation: Produktbeschreibung und bestimmungsgemäße Verwendung. Design- und Entwicklungsbeschreibung, einschließlich der Sicherheitsarchitektur. Die dokumentierte Risikobewertung und ergriffene Maßnahmen. Testberichte und Prüfergebnisse. Die SBOM in maschinenlesbarem Format. Informationen zum Support-Zeitraum. Anweisungen für sichere Installation, Betrieb und Entsorgung. Die EU-Konformitätserklärung.
Dokumentation im Entwicklungsprozess
Dokumentation sollte während der Entwicklung entstehen, nicht nachträglich zusammengestellt werden. Threat Models werden erstellt, wenn das Design entsteht. Testberichte werden generiert, wenn Tests laufen. Architekturentscheidungen werden dokumentiert, wenn sie getroffen werden. Diese Praxis reduziert den Aufwand erheblich und erhöht die Qualität, weil das Wissen noch frisch ist.
Automatisierte Berichte aus CI/CD-Pipelines können direkt in die technische Dokumentation übernommen werden: SAST-Reports, SCA-Reports, SBOM-Dateien, Test Coverage Reports. Documentation-as-Code-Ansätze ermöglichen die Versionierung der Dokumentation zusammen mit dem Code. Bei jedem Release wird eine konsistente Dokumentation generiert, die den Stand des Produkts widerspiegelt.
Herausforderungen bei der SDLC-Einführung
Die Einführung eines Secure Development Lifecycle ist kein triviales Unterfangen. Organisationen, die bisher ohne formalisierte Sicherheitsprozesse entwickelt haben, stehen vor kulturellen, technischen und organisatorischen Herausforderungen. Diese sollten realistisch adressiert werden.
Wie gelingt der kulturelle Wandel?
Security wird traditionell als Aufgabe eines separaten Teams gesehen, das am Ende prüft und Freigaben erteilt. DevSecOps erfordert ein Umdenken: Sicherheit ist Verantwortung aller Entwickler. Dieser kulturelle Wandel braucht Zeit, Schulung und Führungsunterstützung. Quick Wins und positive Beispiele helfen, Akzeptanz zu schaffen.
Tool-Integration und False Positives
Die Integration von Security-Tools in bestehende Pipelines erfordert Aufwand. Noch größer ist die Herausforderung, mit False Positives umzugehen. Ein SAST-Tool, das hunderte Findings produziert, von denen die meisten irrelevant sind, wird schnell ignoriert. Tuning, Baseline-Management und kontextbezogene Priorisierung sind erforderlich, um die Signal-to-Noise-Ratio auf ein akzeptables Niveau zu bringen.
Woher kommt das Security-Know-how?
Secure Development erfordert spezifische Expertise. Threat Modeling, Penetrationstests, sichere Architektur: Diese Fähigkeiten sind am Markt gefragt und teuer. Für KMU ist der Aufbau eines eigenen Security-Teams oft nicht wirtschaftlich. Externe Dienstleister, Schulungsprogramme und der Einsatz von Automatisierung können helfen, die Lücke zu schließen.
Secure Development im internationalen Vergleich
Der CRA steht nicht isoliert. Auch die USA haben sichere Softwareentwicklung zur strategischen Priorität erklärt. Executive Order 14028 vom Mai 2021 verpflichtete Bundesbehörden zur Beschaffung sicherer Software und führte SBOM-Anforderungen für Regierungsaufträge ein. Das NIST Secure Software Development Framework (SSDF) wurde zur Referenz für die gesamte Industrie.
CISA (Cybersecurity and Infrastructure Security Agency) veröffentlichte im April 2023 das Dokument Shifting the Balance of Cybersecurity Risk, das Hersteller auffordert, Sicherheitsverantwortung zu übernehmen statt sie auf Kunden abzuwälzen. Der CISA Secure by Design Pledge von 2024 hat über 200 Unterzeichner, darunter Microsoft, Google und AWS. Die Parallelen zum CRA sind offensichtlich: Beide Ansätze fordern Security-by-Design, SBOM-Transparenz und proaktives Vulnerability Management. Unternehmen, die den NIST SSDF bereits implementieren, haben einen Vorsprung bei der CRA-Compliance.
Fazit und Ausblick
Der Secure Development Lifecycle ist kein Bürokratiemonster. Er ist eine Sammlung bewährter Praktiken, die Sicherheit systematisch in die Entwicklung integrieren. Threat Modeling hilft, Risiken früh zu erkennen, wenn Änderungen noch günstig sind. Sichere Codierrichtlinien und automatisierte Tests finden Schwachstellen, bevor sie Schaden anrichten. Die Integration in CI/CD-Pipelines ermöglicht schnelle Releasezyklen ohne Abstriche bei der Sicherheit.
Ich halte die Kombination aus Automatisierung und menschlicher Expertise für den Schlüssel zum Erfolg. Automatisierte Tools skalieren und finden die offensichtlichen Probleme. Menschliche Expertise ist erforderlich für Threat Modeling, Architekturreview und die Behandlung komplexer Schwachstellen. Weder reine Tool-Abhängigkeit noch rein manueller Ansatz führen zum Ziel.
Die Herausforderungen bei der Einführung sind real, aber lösbar. Ein schrittweiser Ansatz ist sinnvoller als ein Big Bang. Mit SAST und SCA beginnen, dann Threat Modeling einführen, schließlich DAST und Pentests ergänzen. Jeder Schritt verbessert die Sicherheitslage und schafft Grundlagen für den nächsten.
Wer heute einen SDLC einführt, sollte drei Prioritäten setzen: Erstens die Integration von SCA in die Build-Pipeline, um verwundbare Abhängigkeiten zu erkennen. Zweitens die Etablierung von Codierrichtlinien und SAST für neuen Code. Drittens die Dokumentation von Sicherheitsanforderungen und Risikobewertung. Im nächsten Teil betrachten wir, was nach dem Release kommt: Betrieb, Schwachstellenmanagement und die Meldepflichten des CRA.
Quellenverzeichnis
[1] Europäische Union: Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act). Amtsblatt der Europäischen Union L 2024/2847.
[2] Microsoft: Security Development Lifecycle (SDL). https://www.microsoft.com/en-us/securityengineering/sdl/ Dokumentation des Microsoft SDL-Prozesses seit 2004.
[3] OWASP Foundation: Software Assurance Maturity Model (SAMM). Version 2.0, 2020. https://owaspsamm.org/ Framework zur Bewertung und Verbesserung von Software-Sicherheitspraktiken.
[4] OWASP Foundation: Top 10 Web Application Security Risks. Version 2025 (November 2025). https://owasp.org/Top10/2025/ Die meistzitierten Sicherheitsrisiken für Webanwendungen.
[5] MITRE Corporation: Common Weakness Enumeration (CWE). https://cwe.mitre.org/ Katalog von Software- und Hardware-Schwachstellentypen. CWE Top 25 2025: https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html
[6] Shostack, Adam: Threat Modeling: Designing for Security. Wiley, 2014. Standardwerk zu Threat-Modeling-Methoden.
[7] SEI CERT: Secure Coding Standards. Carnegie Mellon University. https://wiki.sei.cmu.edu/confluence/display/seccode Codierrichtlinien für C, C++, Java und andere Sprachen.
[8] NIST: Secure Software Development Framework (SSDF). SP 800-218 Version 1.1, Februar 2022. Ergänzt durch SP 800-218A (Juli 2024) für GenAI/Foundation Models. Rahmenwerk für sichere Softwareentwicklungspraktiken.
[9] CISA: Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. April 2023. Sowie CISA Secure by Design Pledge, 2024. https://www.cisa.gov/securebydesign