Security by Design: Grundprinzipien für Produktteams
Der regulatorische Weckruf: Warum „Security as an Afterthought” Geschichte ist
J’ai assisté à un briefing de l’ANSSI l’année dernière où un responsable a formulé quelque chose que j’avais déjà pressenti depuis longtemps : “La sécurité intégrée n’est plus une option architecturale — c’est une obligation réglementaire.” Auf Deutsch würde das BSI vermutlich genauso klingen.
Der Cyber Resilience Act (CRA) der EU ist seit Oktober 2024 in Kraft — und er verändert die Spielregeln fundamental. Produktteams, die Sicherheit bislang als letzten Schritt vor dem Launch behandelt haben, stehen vor einem strukturellen Problem: Der CRA macht Security by Design zur verbindlichen Anforderung mit echter Marktkonsequenz. Wer nicht konform ist, darf sein Produkt auf dem europäischen Markt schlicht nicht verkaufen.
Frankreich und Deutschland agieren dabei als regulatorische Vorreiter. ANSSI und BSI haben schon vor dem CRA Leitlinien für Product Security veröffentlicht — die BSI TR-03183 zur Cyber-Resilienz von Produkten ist ein konkretes Beispiel dafür. Für Produktteams bedeutet das heute: Sicherheit gehört ab dem ersten Sprint ins Backlog — nicht als separater Workstream, sondern als integraler Bestandteil jeder User Story.
Was Security by Design wirklich bedeutet – jenseits des Buzzwords
Bevor wir über Regulierung sprechen, müssen wir drei Konzepte trennen, die in Produktmeetings regelmäßig durcheinandergeworfen werden:
- Security by Design bedeutet, dass Sicherheitsanforderungen die Architekturentscheidungen von Anfang an formen.
- Security by Default bedeutet, dass Produkte im Auslieferungszustand sicher konfiguriert sind — keine offenen Ports, starke Default-Passwörter, minimale Berechtigungen.
- Reaktive Sicherheitsmaßnahmen sind das, was Teams tun, nachdem ein Incident passiert ist oder ein Pentest Schwachstellen aufgedeckt hat.
Nur die ersten beiden adressieren das Problem strukturell. Die Kernprinzipien, die Security by Design operationalisieren, sind:
- Least Privilege: Jede Komponente, jeder User, jeder Service erhält nur die Rechte, die er tatsächlich braucht.
- Defense in Depth: Mehrere unabhängige Sicherheitsschichten — wenn eine versagt, hält die nächste.
- Fail Securely: Im Fehlerfall soll das System in einen sicheren Zustand wechseln, nicht Daten exponieren.
- Minimierung der Angriffsfläche: Unnötige Funktionen, offene Schnittstellen und nicht genutzte Dienste werden konsequent entfernt.
Ein wichtiger Punkt, den viele Software-Teams übersehen: Der CRA gilt nicht nur für klassische Softwareprodukte. Embedded Systems, IoT-Geräte, industrielle Steuerungsanlagen — alle vernetzten Produkte mit digitalen Elementen fallen in den Anwendungsbereich. Ein Hersteller von Smart-Home-Geräten steht vor denselben Anforderungen wie ein Enterprise-Software-Anbieter.
Regulatorische Anforderungen konkret: Was der CRA von Produktteams verlangt
Der CRA definiert konkrete Pflichten für Hersteller. Die relevantesten für Produktteams:
- Schwachstellenmanagement über den gesamten Produktlebenszyklus — inklusive eines definierten Prozesses zur Offenlegung und Behebung (Vulnerability Disclosure Policy).
- Sicherheitsupdates müssen für einen Mindestzeitraum bereitgestellt werden — der CRA spricht von bis zu fünf Jahren, abhängig von der erwarteten Nutzungsdauer.
- Konformitätserklärung und technische Dokumentation sind Pflicht, nicht Kür.
Die Risikoklassifizierung unter dem CRA ist dabei entscheidend: Produkte werden in Standardprodukte, kritische Produkte Klasse I (z.B. Passwortmanager, Browser, VPN-Software) und kritische Produkte Klasse II (z.B. Hypervisoren, Firewalls, industrielle Steuerungssysteme) eingeteilt. Klasse-II-Produkte erfordern eine externe Konformitätsbewertung durch eine notifizierte Stelle — das ist operativ und finanziell deutlich aufwändiger.
Der CRA existiert nicht im Vakuum. Produktteams müssen auch die Schnittstellen zu NIS2, der Radio Equipment Directive (RED) für Funkgeräte und dem europäischen Cybersecurity-Zertifizierungsrahmen (EUCC) im Blick behalten. Wer ein vernetztes Produkt mit Funk-Schnittstelle entwickelt, bewegt sich möglicherweise gleichzeitig unter drei Regelwerken.
Security by Design operativ verankern: Von der Theorie zur Produktpraxis
Der häufigste Fehler: Teams lesen die regulatorischen Anforderungen und fragen sich, wie sie Compliance-Dokumente produzieren. Die richtige Frage ist: Wie verändern wir unseren Entwicklungsprozess?
Threat Modeling ist der Einstiegspunkt. Methoden wie STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) oder PASTA (Process for Attack Simulation and Threat Analysis) helfen Teams, Bedrohungen systematisch zu identifizieren — bevor eine einzige Zeile Code geschrieben wird. Ein Threat-Modeling-Workshop zu Beginn eines neuen Features kostet einen halben Tag. Ein Security-Redesign nach dem Launch kostet Wochen.
Der Secure Development Lifecycle (SDL) integriert Security Gates in den Entwicklungsprozess. In Agile-Umgebungen bedeutet das konkret: Security-Akzeptanzkriterien in User Stories, automatisierte Security-Checks in der CI/CD-Pipeline, und regelmäßige Security Reviews als Teil der Definition of Done — nicht als separater Prozess, der Velocity kostet.
Das Tooling ist heute gut verfügbar:
- SAST (Static Application Security Testing) analysiert Code auf bekannte Schwachstellenmuster.
- DAST (Dynamic Application Security Testing) testet laufende Anwendungen gegen Angriffsvektoren.
- SCA (Software Composition Analysis) identifiziert Schwachstellen in Drittanbieter-Bibliotheken.
- Die SBOM (Software Bill of Materials) dokumentiert alle Softwarekomponenten — und wird vom CRA explizit als Anforderung adressiert.
Organisatorische Voraussetzungen: Security als Teamverantwortung
Hier wird es unbequem: Ein einzelnes Security-Team kann Product Security nicht alleine tragen. Die Kapazität fehlt, die Nähe zum Code fehlt, und die Incentives sind falsch ausgerichtet.
Das Security Champions-Modell ist die praktischere Alternative: Entwickler aus jedem Team, die eine vertiefte Security-Ausbildung erhalten und als Multiplikatoren wirken. Sie übersetzen abstrakte Sicherheitsanforderungen in konkrete Implementierungsentscheidungen — und sie sitzen im selben Daily Standup wie das restliche Team.
Die Governance-Frage ist in vielen Unternehmen ungeklärt: Wer trägt die Verantwortung für Product Security — der CISO oder der CPO? Die ehrliche Antwort ist: beide, mit klar definierten Zuständigkeiten. Der CISO setzt Rahmen und Standards, der CPO trägt operative Verantwortung für die Umsetzung im Produkt. Wo diese Zuständigkeit unklar ist, entsteht genau die organisatorische Lücke, die der CRA adressiert.
Typische Fallstricke und wie Produktteams sie vermeiden
“Compliance is not security.” — Das hört man in Sicherheitskreisen oft, und es stimmt. Aber die Umkehrung gilt auch: Fehlende Compliance ist ein Marktrisiko.
Das Anti-Pattern Security Theatre kennt jeder, der Audits begleitet hat: Checklisten werden abgehakt, Dokumentation wird produziert — aber die eigentliche Risikoreduktion bleibt aus. Erfahrene Auditoren erkennen das. Sie schauen nicht nur auf Dokumente, sondern fragen: Welche Schwachstellen wurden im letzten Quartal gefunden, wie schnell wurden sie behoben, und was hat das Team daraus gelernt?
Die Kostenfalle Late-Stage Security ist gut belegt: Das NIST hat bereits früh dokumentiert, dass Sicherheitslücken, die erst nach dem Deployment behoben werden, im Schnitt 30-mal teurer sind als präventive Maßnahmen in der Design-Phase. Ein nachträglicher Security-Fix in einem vernetzten IoT-Produkt kann zudem ein Firmware-Update erfordern, das koordiniert über Millionen von Geräten ausgerollt werden muss.
Fehlende technische Dokumentation ist unter dem CRA kein Kavaliersdelikt mehr. Die Marktüberwachungsbehörden können Dokumentation anfordern — und wer sie nicht liefern kann, riskiert Marktrücknahmen.
Take-aways & nächste Schritte: So startet Ihr Produktteam heute
Die drei unmittelbaren Maßnahmen, die ich jedem Produktteam empfehlen würde:
- Threat-Modeling-Workshop ansetzen — für das aktuelle Produkt oder das nächste größere Feature. Einen halben Tag investieren, Bedrohungen strukturiert erfassen.
- SBOM-Prozess etablieren — welche Drittanbieter-Bibliotheken sind im Einsatz, welche Versionen, welche bekannten Schwachstellen? Das ist die Basis für CRA-konforme Dokumentation.
- CRA-Reifegrad bewerten — welche Produktkategorie trifft auf Ihr Produkt zu, welche Pflichten entstehen daraus, und wo gibt es aktuell Gaps?
Der CRA-Übergangszeitraum läuft bis Ende 2027 — das klingt weit, ist aber für Unternehmen mit komplexen Produktportfolios bereits heute knapp. Wer jetzt mit der Analyse beginnt, hat die Wahl. Wer wartet, hat sie nicht mehr.
EACG unterstützt Produktteams bei der regulatorischen Einordnung, der Implementierung eines Secure Development Lifecycle und der Vorbereitung auf CRA-Konformität — von der Gap-Analyse bis zur technischen Dokumentation. Ein unverbindliches Erstgespräch gibt Orientierung, bevor die Regulierung zur Fristfrage wird.
Gastbeitrag. Tech-Journalistin, EACG ist regulatorische Quelle. Nicht vergütet.