Security by Design nach CRA: Anforderungen & Checkliste
Security by Design ist CRA-Kernpflicht bis 2027: Integrieren Sie Sicherheit von Anfang an in Entwicklung. Methoden, SDL-Prozess, Checkliste für Hersteller.
Der Cyber Resilience Act macht Security by Design zur verbindlichen Anforderung für alle Produkte mit digitalen Elementen. Sicherheit darf nicht länger nachträglich hinzugefügt werden, sondern muss von der ersten Konzeptidee bis zum Produktlebensende systematisch berücksichtigt werden. Dieser Artikel zeigt, wie Unternehmen den Paradigmenwechsel von reaktiver zu proaktiver Produktsicherheit vollziehen.
Was bedeutet Security by Design?
Security by Design (SbD) ist ein Entwicklungsansatz, bei dem Sicherheitsaspekte von Anfang an in den Entwurf und die Architektur eines Produkts integriert werden. Anstatt Sicherheitslücken nach der Fertigstellung zu flicken, werden potenzielle Angriffsvektoren bereits in der Konzeptionsphase identifiziert und durch architektonische Entscheidungen eliminiert oder minimiert.
Ob Ihr Produkt unter die CRA-Anforderungen für Security by Design fällt, können Sie mit unserem CRA Self-Check-Tool ermitteln. Das Tool bietet Ihnen eine schnelle Übersicht über Ihre Verpflichtungen.
Das Prinzip lässt sich auf drei Kerngedanken reduzieren: Sicherheit wird nicht nachgerüstet, sondern eingebaut. Sicherheitsentscheidungen werden früh getroffen, wenn Änderungen noch kostengünstig sind. Sicherheit ist Teamaufgabe, nicht alleinige Verantwortung einer Sicherheitsabteilung.
Der Begriff geht auf die Arbeiten von Saltzer und Schroeder aus den 1970er Jahren zurück, die grundlegende Prinzipien wie das Least-Privilege-Prinzip, Defense in Depth und Fail-Safe-Defaults formulierten. Diese Prinzipien haben bis heute nichts an Relevanz verloren – der CRA verleiht ihnen nun regulatorischen Nachdruck.
Security by Design und Security by Default im CRA
Der Cyber Resilience Act verwendet die Begriffe „Security by Design" und „Security by Default" als zentrale Leitprinzipien. Während Security by Design den Entwicklungsprozess adressiert, bezieht sich Security by Default auf den Auslieferungszustand des Produkts.
Security by Design im CRA-Kontext
Anhang I Teil I des CRA fordert, dass Produkte mit digitalen Elementen so konzipiert, entwickelt und hergestellt werden, dass sie über den gesamten Lebenszyklus ein angemessenes Cybersicherheitsniveau gewährleisten. Konkret bedeutet dies:
Risikobewertung in der Entwurfsphase: Hersteller müssen eine Cybersicherheits-Risikobewertung durchführen, bevor das Produkt in Verkehr gebracht wird. Diese Bewertung muss während des gesamten Lebenszyklus aktualisiert werden.
Minimierung der Angriffsfläche: Produkte sollen so konzipiert sein, dass die Angriffsfläche – also die Summe aller potenziellen Einfallstore für Angreifer – auf ein Minimum reduziert wird.
Schutz vor unbefugtem Zugriff: Geeignete Mechanismen zum Schutz vor unbefugtem Zugriff müssen bereits in der Architektur vorgesehen sein, nicht erst als nachträgliche Erweiterung.
Schutz der Vertraulichkeit und Integrität: Die Architektur muss den Schutz gespeicherter, übertragener und verarbeiteter Daten gewährleisten – durch Verschlüsselung, Zugangskontrollen und Integritätsprüfungen.
Security by Default im CRA-Kontext
Security by Default verlangt, dass Produkte in einer sicheren Standardkonfiguration ausgeliefert werden. Konkrete Anforderungen des CRA umfassen:
Keine Standardpasswörter: Produkte dürfen nicht mit werksseitig voreingestellten Passwörtern ausgeliefert werden, die für alle Geräte identisch sind. Entweder muss ein eindeutiges Passwort pro Gerät generiert werden, oder der Nutzer muss bei der Erstinbetriebnahme zur Passworterstellung gezwungen werden.
Minimale Berechtigungen: Standardkonfigurationen sollen dem Prinzip der minimalen Berechtigungen folgen. Funktionen, die nicht benötigt werden, sollen deaktiviert sein.
Sichere Kommunikation: Standardmäßig sollen sichere Kommunikationsprotokolle und Verschlüsselung aktiviert sein.
Die Kombination beider Prinzipien stellt sicher, dass ein Produkt sowohl sicher entwickelt als auch sicher ausgeliefert wird – und damit vom ersten Einsatztag an ein angemessenes Schutzniveau bietet.
Der Secure Development Lifecycle (SDLC)
Die praktische Umsetzung von Security by Design erfolgt durch die Integration von Sicherheitsaktivitäten in den Software Development Lifecycle (SDLC). Ein sicherer SDLC ist kein separater Prozess, sondern die Erweiterung des bestehenden Entwicklungsprozesses um Sicherheitsaspekte in jeder Phase.
Phase 1: Anforderungsanalyse
In der Anforderungsphase werden neben funktionalen Anforderungen auch Sicherheitsanforderungen definiert. Dies umfasst die Identifikation von Compliance-Anforderungen (hier: CRA), die Definition von Schutzzielen (Vertraulichkeit, Integrität, Verfügbarkeit) und die Festlegung von Sicherheitsanforderungen an Schnittstellen und Datenverarbeitung.
Praktische Maßnahmen in dieser Phase sind Security-Workshops mit Stakeholdern, die Erstellung eines Risikoprofils und die Dokumentation von Sicherheitsanforderungen im Anforderungskatalog.
Phase 2: Design und Architektur
Die Designphase ist entscheidend für Security by Design, da hier die architektonischen Grundlagen gelegt werden. Zentrale Aktivitäten sind Threat Modeling, die Auswahl sicherer Architekturmuster und die Definition von Sicherheitskontrollen.
Threat Modeling ist eine strukturierte Methode zur Identifikation und Bewertung von Bedrohungen. Verbreitete Frameworks sind STRIDE (Microsoft), PASTA und Attack Trees. Das Ergebnis ist ein Bedrohungsmodell, das potenzielle Angriffsvektoren und entsprechende Gegenmaßnahmen dokumentiert.
STRIDE-Kategorien für Threat Modeling:
┌─────────────────────────────────────────────────────────┐
│ S - Spoofing → Identitätsvortäuschung │
│ T - Tampering → Datenmanipulation │
│ R - Repudiation → Abstreitbarkeit │
│ I - Information → Informationsoffenlegung │
│ D - Denial of Serv. → Dienstverweigerung │
│ E - Elev. of Priv. → Rechteausweitung │
└─────────────────────────────────────────────────────────┘
Für jede identifizierte Bedrohung werden Gegenmaßnahmen definiert, die in der Architektur verankert werden. Dies kann beispielsweise die Einführung einer Authentifizierungsschicht, die Implementierung von Input-Validierung oder die Festlegung von Verschlüsselungsstandards sein.
Phase 3: Implementierung
In der Implementierungsphase werden sichere Coding-Standards angewendet und durch automatisierte Prüfungen unterstützt. Wesentliche Elemente sind Secure Coding Guidelines, die Definition verbotener Funktionen und Muster sowie die Integration von Static Application Security Testing (SAST) in die Build-Pipeline.
Secure Coding Guidelines sollten sprachspezifisch sein und konkrete Vorgaben für häufige Sicherheitsprobleme enthalten. Die OWASP Foundation bietet umfassende Ressourcen, darunter den OWASP Secure Coding Practices Guide und sprachspezifische Cheat Sheets.
Beispiel einer Secure Coding Checklist:
- Alle Eingaben werden validiert (Whitelist-Ansatz)
- Ausgaben werden kontextspezifisch kodiert
- Authentifizierung erfolgt über bewährte Bibliotheken
- Passwörter werden mit bcrypt/Argon2 gehasht
- Sitzungsmanagement nutzt sichere Tokens
- Fehlerbehandlung gibt keine sensiblen Informationen preis
- Logging enthält keine personenbezogenen Daten
- Kryptografische Operationen nutzen aktuelle Algorithmen
- Abhängigkeiten werden auf bekannte Schwachstellen geprüft
Phase 4: Testen und Verifizierung
Die Testphase umfasst neben funktionalen Tests auch dedizierte Sicherheitstests. Die CRA-Anforderung, Produkte ohne bekannte ausnutzbare Schwachstellen auszuliefern, macht umfassende Sicherheitstests obligatorisch.
Static Application Security Testing (SAST) analysiert den Quellcode ohne Ausführung und identifiziert Muster, die auf Schwachstellen hindeuten. Tools wie SonarQube, Semgrep oder Checkmarx können in CI/CD-Pipelines integriert werden.
Dynamic Application Security Testing (DAST) prüft die laufende Anwendung durch Simulation von Angriffen. Tools wie OWASP ZAP oder Burp Suite automatisieren typische Angriffsszenarien wie SQL-Injection oder Cross-Site-Scripting.
Software Composition Analysis (SCA) prüft verwendete Drittanbieterkomponenten auf bekannte Schwachstellen. Im Kontext des CRA ist dies besonders relevant, da Hersteller auch für Schwachstellen in eingebundenen Open-Source-Komponenten verantwortlich sind. Tools wie Trivy, Snyk oder Dependency-Check scannen die SBOM gegen Schwachstellendatenbanken.
Penetration Testing durch interne oder externe Sicherheitsexperten ergänzt die automatisierten Tests durch kreative, kontextbezogene Angriffssimulationen.
Phase 5: Deployment und Betrieb
Auch nach dem Deployment enden die Security-by-Design-Aktivitäten nicht. Der CRA fordert explizit die Aufrechterhaltung der Sicherheit über den gesamten Supportzeitraum.
Sichere Deployment-Praktiken umfassen die Härtung von Produktionsumgebungen, die Implementierung von Monitoring und Alerting sowie die Einrichtung von Update-Mechanismen für Sicherheitspatches.
Kontinuierliches Monitoring ermöglicht die frühzeitige Erkennung von Sicherheitsvorfällen und ist Voraussetzung für die Einhaltung der Meldepflichten nach CRA.
Integration in bestehende Entwicklungsprozesse
Die Einführung von Security by Design erfordert keine vollständige Umstellung des Entwicklungsprozesses, sondern die Anreicherung bestehender Abläufe um Sicherheitsaspekte.
Agile Entwicklung und Security
In agilen Umgebungen werden Sicherheitsanforderungen als User Stories oder Akzeptanzkriterien formuliert. Security-Aktivitäten werden in Sprint-Zeremonien integriert, beispielsweise Threat Modeling im Sprint Planning oder Security-Reviews in der Sprint-Retrospektive.
Ein bewährtes Modell ist die Einführung von Security Champions – Entwickler mit besonderer Sicherheitsaffinität, die als Ansprechpartner im Team fungieren und Sicherheitswissen verbreiten. Der OWASP Security Champions Guide bietet Anleitungen für die Einführung solcher Programme.
DevSecOps
DevSecOps erweitert DevOps um Sicherheitsaspekte und automatisiert Sicherheitsprüfungen in CI/CD-Pipelines. Typische Integrationen umfassen SAST-Scans bei jedem Commit, SCA-Scans zur Prüfung von Abhängigkeiten, DAST-Scans in Staging-Umgebungen, automatisierte Compliance-Checks und Secrets-Detection zur Verhinderung von Credential-Leaks.
Beispiel einer Security-integrierten Pipeline:
.gitlab-ci.yml - Security-integrierte Pipeline
stages:
- build
- test
- security
- deploy
build:
stage: build
script:
- npm ci
- npm run build
unit-tests:
stage: test
script:
- npm run test
sast-scan:
stage: security
image: returntocorp/semgrep
script:
- semgrep --config=auto --sarif -o semgrep-results.sarif .
artifacts:
reports:
sast: semgrep-results.sarif
dependency-check:
stage: security
image: aquasec/trivy:latest
script:
- trivy fs --scanners vuln --format sarif -o trivy-results.sarif .
artifacts:
reports:
dependency_scanning: trivy-results.sarif
secrets-detection:
stage: security
image: zricethezav/gitleaks:latest
script:
- gitleaks detect --source . --report-format sarif --report-path gitleaks-results.sarif
artifacts:
reports:
secret_detection: gitleaks-results.sarif
deploy-staging:
stage: deploy
script:
- ./deploy.sh staging
only:
- main
Praktische Umsetzung: Ein 5-Schritte-Plan
Die Einführung von Security by Design in einer Organisation erfordert einen strukturierten Ansatz. Die folgenden Schritte bieten einen pragmatischen Einstieg:
Schritt 1: Bestandsaufnahme (2-4 Wochen)
Analysieren Sie den aktuellen Reifegrad Ihrer Sicherheitspraktiken. Hilfreiche Frameworks für diese Bewertung sind das OWASP Software Assurance Maturity Model (SAMM) oder das Building Security In Maturity Model (BSIMM). Identifizieren Sie Lücken zwischen aktuellem Stand und CRA-Anforderungen.
Schritt 2: Governance etablieren (4-8 Wochen)
Definieren Sie Rollen und Verantwortlichkeiten für Produktsicherheit. Mindestens sollten ein Product Security Officer und Security Champions in den Entwicklungsteams benannt werden. Erstellen Sie Richtlinien für Secure Coding, Threat Modeling und Sicherheitstests.
Schritt 3: Prozesse integrieren (8-12 Wochen)
Integrieren Sie Sicherheitsaktivitäten in bestehende Entwicklungsprozesse. Priorisieren Sie zunächst die Maßnahmen mit dem besten Kosten-Nutzen-Verhältnis, typischerweise automatisierte SAST- und SCA-Scans in der CI/CD-Pipeline.
Schritt 4: Teams befähigen (fortlaufend)
Investieren Sie in Schulungen für Entwicklungsteams. Das OWASP bietet umfangreiche kostenlose Trainingsressourcen, darunter die Web Security Testing Guide und die Secure Coding Practices. Etablieren Sie ein Security-Champions-Programm für nachhaltige Wissensvermittlung.
Schritt 5: Kontinuierliche Verbesserung (fortlaufend)
Messen Sie die Wirksamkeit Ihrer Maßnahmen durch Metriken wie die Anzahl gefundener Schwachstellen pro Release, die Mean Time to Remediation oder die Abdeckung durch Sicherheitstests. Nutzen Sie diese Daten zur kontinuierlichen Optimierung.
Verknüpfung mit anderen CRA-Anforderungen
Security by Design steht nicht isoliert, sondern ist eng mit anderen CRA-Pflichten verzahnt:
SBOM-Erstellung: Eine vollständige SBOM-Erstellung und -Pflege ist Voraussetzung für effektives Schwachstellenmanagement. Die SBOM dokumentiert alle Komponenten, die im Security-by-Design-Prozess geprüft und abgesichert werden.
Schwachstellenmanagement: Security by Design reduziert die Anzahl von Schwachstellen, eliminiert sie aber nicht vollständig. Ein robustes Schwachstellenmanagement im Produktlebenszyklus ergänzt die präventiven Maßnahmen durch reaktive Prozesse.
Technische Dokumentation: Die CRA-geforderte technische Dokumentation muss die Ergebnisse von Risikobewertungen und Sicherheitstests enthalten – Dokumente, die im Security-by-Design-Prozess entstehen.
Update-Fähigkeit: Die Architektur muss von Anfang an sichere Update-Mechanismen vorsehen, um Sicherheitspatches über den gesamten Supportzeitraum bereitstellen zu können.
Für eine ganzheitliche CRA-Compliance ist die Integration aller Bausteine erforderlich. Unser CRA-Leitfaden mit Umsetzungsfahrplan zeigt, wie die einzelnen Elemente zusammenspielen.
Security by Design professionell umsetzen
- CRA-Compliance: Begleitung von Security by Design bis CE-Kennzeichnung
- SBOM erstellen: Software Bill of Materials für CRA
- Schwachstellen managen: Lifecycle Vulnerability Management
Häufige Fehler und wie man sie vermeidet
Bei der Einführung von Security by Design treten regelmäßig vermeidbare Fehler auf:
Sicherheit als Silo: Security by Design funktioniert nicht, wenn Sicherheit ausschließlich von einer separaten Abteilung verantwortet wird. Sicherheit muss Teil der Entwicklungskultur werden.
Zu spät beginnen: Threat Modeling nach Abschluss der Architektur ist wenig effektiv. Die größten Sicherheitsgewinne entstehen durch frühzeitige Designentscheidungen.
Tooling überbewerten: Automatisierte Tools sind wertvoll, ersetzen aber nicht das Sicherheitsdenken der Entwickler. Training und Awareness sind ebenso wichtig.
Altprodukte ignorieren: Der CRA gilt auch für Produkte, die bereits vor Dezember 2027 entwickelt wurden, sofern sie nach diesem Datum verkauft werden. Auch Altprodukte müssen auf CRA-Konformität geprüft werden.
Dokumentation vernachlässigen: Die CRA-geforderte technische Dokumentation erfordert nachweisbare Prozesse. Undokumentierte Sicherheitsmaßnahmen sind im Konformitätsbewertungsverfahren wertlos.
Fazit: Security by Design bringt Vorteile
Security by Design ist mehr als eine regulatorische Pflicht – es ist ein Qualitätsmerkmal, das Produkte sicherer, robuster und vertrauenswürdiger macht. Unternehmen, die Sicherheit von Anfang an mitdenken, reduzieren nicht nur das Risiko von Sicherheitsvorfällen, sondern auch die Kosten für nachträgliche Korrekturen.
Die CRA-Fristen setzen einen klaren Zeitrahmen: Bis Dezember 2027 müssen alle Produkte mit digitalen Elementen die Security-by-Design-Anforderungen erfüllen. Unternehmen, die jetzt mit der Umstellung beginnen, haben ausreichend Zeit, Prozesse zu etablieren und Erfahrungen zu sammeln.
Der Aufwand für die Einführung von Security by Design zahlt sich mehrfach aus: durch reduzierte Schwachstellen, geringere Kosten für Nachbesserungen, Compliance mit dem CRA und gestärktes Vertrauen von Kunden und Partnern.
Professionelle Unterstützung
Security by Design erfordert Fachwissen und strukturierte Prozesse. Eine professionelle Beratung hilft Ihrem Unternehmen, sichere Entwicklungspraktiken nachhaltig zu implementieren und CRA-Konformität zu erreichen.
- Cyber Resilience Act Beratung: Etablierung von Security-by-Design-Prozessen, SDLC-Integration und DevSecOps-Implementierung für produktsichere Entwicklung.
Externe Ressourcen: